atari-home.de - Foren

Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Di 08.03.2016, 14:01:03

Titel: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 08.03.2016, 14:01:03
Habe mir den Artikel von Heise gekauft aber leider ist die Qualität der Scans so schlecht das man rein garnichts beim Schaltplan erkennen kann.

Hat jemand die Ausgabe und kann mal den Schaltplan in 300dpi einscannen ?
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 08.03.2016, 19:07:34
Habe mal das IDE Listing aus der c´t mit JEDI übersetzt. Ich musste nur die Klammern auflösen da JEDI das wohl nicht versteht ...

// 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 + LDS &  RW & CS1;
     
IOWR     = LDS & /RW & CS0 + LDS & /RW & CS1 + LDS & /RW & TOS; % Signal TOS wegen EEPROMs %

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

*END



Jetzt fehlt mir nur noch der Schaltplan zum Interface aus der (Allesfresser) c't 09/1993 ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Di 08.03.2016, 19:17:29
Du könntest -- zumindest, um zu sehen, was passiert -- beim Heise-Verlag reklamieren. Immerhin hast Du für einen Artikel mit lesbaren Grafiken bezahlt.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 08.03.2016, 19:33:34
Habe mal jemanden gefragt, wenn das nichts ergibt kann ich das mal machen. Ich vermute mal das die c´t Jahrgang DVD auch nicht besser ist ...
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Di 08.03.2016, 19:39:58
Ich bezweifel das die diese Alten Ausgaben in besserer Qualität haben. Hab das auch schonmal gekauft und sehr unleserlich.
Titel: Re: c´t IDE Interface ...
Beitrag von: Arthur am Di 08.03.2016, 19:40:26
Habe mal jemanden gefragt, wenn das nichts ergibt kann ich das mal machen. Ich vermute mal das die c´t Jahrgang DVD auch nicht besser ist ...

Ja die sind genau so bescheiden... das betrifft die Jahrgänge 1990-2003 davor sind es PDF und danach meine ich, sind es auch wieder PDF.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 08.03.2016, 19:49:23
PDF ist doch in Ordnung aber es sieht so aus als ob die Bilder 10dpi Scans sind und die größeren Bild Dateien die beiliegen sind genau so schlecht. Da kann man keine Zahl oder Buchstaben lesen/erkennen ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Arthur am Di 08.03.2016, 20:01:18
Die PDFs sind gut... wie eine original C't nur als PDF... aber der HTML-Dreck von 1990-2003 geht gar nicht... :-[
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 09.03.2016, 19:52:57
Habe den Scan in guter Qualität, löte das Teil auch schon zusammen ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 11.03.2016, 21:57:32
Das Interface läuft aber macht noch Probleme. Ich habe keine HCT244/245 und habe nur F244 und LS244 sowie LS245. Mit den LS Treibern in den Datenleitungenn läuft es nicht, habe deshalb Brücken gesteckt. Mit dem F244 läuft es nicht richtig, der LS244 geht so allerdings lassen sich nur kleine Programme starten incl. dem HDDriver.sys im Rootverzeichnis auf C:\ also bootet der Rechner die CF einwandfrei. Habe jetzt erstmal bei Kessler die fehlenden Bausteine bestellt. Vielleicht liegt es aber doch am GAL ?

(http://forum.atari-home.de/index.php?action=dlattach;topic=12775.0;attach=10766;image)
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 12.03.2016, 12:14:47
Das ist schon ein sehr schönes Teil. Vielleicht überwinde ich mich mal versuche mich doch mal an einer Platine in Eagle, mal schauen ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Sa 12.03.2016, 12:28:09
Sind die Treiber-ICs denn jetzt da? Oder läuft's ohne Treiber stabil?
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 12.03.2016, 12:40:26
Nein, noch nicht da aber ich bin zuversichtlich.

Alles unter 30kB läuft, da ist bestimmt eine minimale Verzögerung wenn erst die Treiberbausteine umgeschaltet werden über das G Signal, keine Ahnung. Seltsamerweise läuft es gar nicht wenn ich die Signale am 244 Brücke, mit Baustein alles gut ...
Titel: Re: c´t IDE Interface ...
Beitrag von: skul am So 13.03.2016, 22:32:03
Moin,

auf den Treiber für die Steuersignale (244) kann man nicht verzichten. Wenn sonst nicht gerade zwanzig Erweiterungen am Datenbus hängen, kann man auf die bidirektionalen Treiber verzichten. Ich hatte auch mit Pak3 und Romportkram ohne die 245er keine Probleme.
Auf- und Umrüstung von STs auf TOS2.06, HD-Floppy und IDE-Port: Ein Gal 20v8, zwei Eproms, ein Treiber 244, Pfostenleiste 40pol (oder 44), etwas Draht - fertig. Hab davon bestimmt 30-40 Stück gebaut, alles ohne Probleme. Eine Platine kam oft nicht in Frage, weil bei einigen 1040ern die CPU vorn am Rand unter der Tastatur liegt. Geht eh nicht und die freie Verdrahtung dauert nicht wirklich länger als der Platineneinbau (war auch 'ne Kostenfrage :-)).

Gruß
skul
 

Gruß
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 17.03.2016, 14:34:51
Die Kessler Bauteile sind da und mit dem HCT244 läuft das Interface jetzt einwandfrei.

Allerdings funktioniert es nicht mehr wenn die beiden HCT245 Treiber für die Datenleitungen einsetze. Habe auch noch ein anderes JED File von skul bekommen aber mit beiden das gleiche verhalten. Wenn die Schaltung in Ordnung ist muss da ein Fehler beim GAL sein ...

Ich bin erstmal froh das es so jetzt funktioniert.
Titel: Re: c´t IDE Interface ...
Beitrag von: Arthur am Do 17.03.2016, 16:13:08
Moin,

auf den Treiber für die Steuersignale (244) kann man nicht verzichten. Wenn sonst nicht gerade zwanzig Erweiterungen am Datenbus hängen, kann man auf die bidirektionalen Treiber verzichten. Ich hatte auch mit Pak3 und Romportkram ohne die 245er keine Probleme.

Bietet den so ein Treiber nicht auch einen Schutz für die CPU oder so?

Die Kessler Bauteile sind da und mit dem HCT244 läuft das Interface jetzt einwandfrei.

Allerdings funktioniert es nicht mehr wenn die beiden HCT245 Treiber für die Datenleitungen einsetze. Habe auch noch ein anderes JED File von skul bekommen aber mit beiden das gleiche verhalten. Wenn die Schaltung in Ordnung ist muss da ein Fehler beim GAL sein ...

Ich bin erstmal froh das es so jetzt funktioniert.

Hallo Frank, klasse Leistung... ein Benchmark mit Howfast (http://www.newtosworld.de/downloads/tools/howfast/download) wäre noch interessant.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 17.03.2016, 16:33:34
Was soll da schneller oder langsamer sein. Meine MonSTer kommt auf 1290kb und das c´t Interface ist genau so schnell, um genau zu sein auf 1300kB. Ich habe noch kein IDE Interface gesehen das da auf einem normalen ST von ausbricht. Die SCSI Platte mit dem Hostadapter von Wolfgang Förster ist genau so schnell, das bedeutet wohl das man da nicht mehr heraus bekommt.


Bietet den so ein Treiber nicht auch einen Schutz für die CPU oder so?

Wieso Schutz? Der Romport oder wenn man eine Erweiterung auf die CPU setzt ist da auch nichts geschützt. Was ich mir vorstellen kann ist das man vielleicht extrem lange IDE Kabel benutzen kann. Aber wer braucht das schon. Wäre natürlich trotzalledem schön wenn das Interface mit den beiden Treibern laufen würde ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 30.06.2016, 12:30:09
Die beiden 245iger Treiber funktionieren nicht ...

Ich hatte damals so ein Interface von eMedia oder wie der Vertriebsladen von Heise hieß und da funktionierte alles wunderbar.

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. Das Interface funktioniert ohne die beiden Treiber wunderbar mit einem Master und einem Slave Device.

Hat jemand eine Idee wegen dem GAL ?

Die GAL Quelldatei ist im zweiten Beitrag ...
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Do 30.06.2016, 13:19:47
Hallo Frank, ich hab das interface jetzt mit einem cpld nachgebildet, hab ein dev board bestellt aber ist noch nicht da. Dort hab ich alle datenleitungen mit durch den cpld geschleusst so das keine bustreiber notwendig sind. ich berichte wenn ich gegestet habe.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 30.06.2016, 13:42:55
Hallo Ingo, ich will/möchte das ja so weit original mit dem 20V8 aufbauen. Das hilft mir das da doch bestimmt nicht weiter, oder ?

Ich könnte mir Vorstellen das es verschiedene Versionen des GALs gab und diese nicht ganz funktionierende irgendwie im Netz gelandet ist. Den original Autor ausfindig machen und vielleicht kann er helfen wäre vielleicht was ...

Das GAL Listing steht doch gar nicht im Artikel, oder ?
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Do 30.06.2016, 16:03:16
Wenn du mir den Schaltplan mal zusenden könntest dann kann ich ihn mir nochmal anschauen und das GAL Listing vergleichen.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Do 30.06.2016, 18:48:06
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...)
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 30.06.2016, 18:52:13
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Do 30.06.2016, 18:58:08
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Do 30.06.2016, 19:04:03
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.

Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Do 30.06.2016, 19:17:28
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 30.06.2016, 19:21:32
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 ?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Do 30.06.2016, 19:35:51
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.

Zitat
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Do 30.06.2016, 19:48:45
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
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am Fr 01.07.2016, 09:27:35
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Fr 01.07.2016, 11:37:27
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".
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Fr 01.07.2016, 15:12:50
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 01.07.2016, 15:28:26
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 ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Fr 01.07.2016, 22:53:17
Das GAL nach der Idee von czietz ist auf dem Weg, mal schauen ob es damit geht oder nicht ...

Ich bin gespannt.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am So 03.07.2016, 09:41:13
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.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 03.07.2016, 11:34:05
@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 ?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 03.07.2016, 11:42:07
@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.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am So 03.07.2016, 14:22:57
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 (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.
Titel: Re: c´t IDE Interface ...
Beitrag von: neogain am So 03.07.2016, 15:22:24
@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.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am So 03.07.2016, 17:26:23
@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.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 03.07.2016, 18:37:51
Wie gesagt ich hatte das damals als Bausatz also Platine plus fertig programmiertes GAL gekauft. Aufgebaut und funktionierte Einwandfrei ...

Also entweder stimmt der Plan nicht oder das GAL, ich tippe mal auf das GAL !
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 03.07.2016, 21:31:21
... oder die Festplatte damals war -- wie von Soldergirl auch schon vermutet -- einfach langsamer und nicht so empfindlich auf grenzwertiges Timing. Oder der Lochrasteraufbau ist empfindlicher als eine geätzte Leiterkarte. Oder...

Ich wüsste nicht, was im Schaltplan falsch sein sollte. Der ist ja doch sehr simpel. Das GAL könnte natürlich anders gewesen sein. Sofern Du aber kein Original-GAL zum Vergleich findest, wird es schwer sein, das herauszufinden.

Wenn man mal pperas Interface zum Vergleich nimmt, ist -- neben schon angemerkte der Ansteuerung des 74HCT245 -- noch die Erzeugung von DTACK unterschiedlich. Das c't-Interface beachtet dafür noch IOCHRDY des IDE-Busses.
Titel: Re: c´t IDE Interface ...
Beitrag von: neogain am So 03.07.2016, 21:42:13
Mich würde auch ein funktionierendes ct Interface interessieren, weil ich auch gerne auf dem mega st laufen lassen möchte. Ich habe in diesem Zusammenhang Bedenken, dass dieses so nicht funktionieren wird. Mal schauen was kommt...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 03.07.2016, 21:50:57
Ich vermute mal mit der Platte hat das wenig zu tun. Ich hatte das mit CF Karte, eine alte mit 512MB.
Titel: Re: c´t IDE Interface ...
Beitrag von: neogain am So 03.07.2016, 22:55:41
Was ich meinte war Mint. Daher die bedenken
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 03.07.2016, 23:10:40
Was hat ein IDE Interface mit MiNT zu tun ?
Titel: Re: c´t IDE Interface ...
Beitrag von: neogain am Mo 04.07.2016, 19:38:21
Was hat ein IDE Interface mit MiNT zu tun ?

Braucht Mint nicht HDDriver? oder bringt Mint seine eigenen Treiber mit?
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Mo 04.07.2016, 22:15:26
Mint liegt im Autoordner und da wurde HDDriver ja schon geladen also ja Mint braucht auch einen HD-Driver.
Titel: Re: c´t IDE Interface ...
Beitrag von: neogain am Di 05.07.2016, 15:03:59
So hatte ich das vermutet. Wenn meine altram Geschichte läuft probiere ich das aus. Ansonsten mache ich die nackte ST Platine fertig für Mint.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 05.07.2016, 15:16:04
MiNT hat mit einem bestimmten Plattentreiber erstmal nichts zu tun. Da kann auch der AHDI oder der von ppera benutzt werden oder sonst was ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 06.07.2016, 12:15:02
"G" wird immer aktiviert wenn gelesen oder geschrieben wird wegen RW und nicht RW in der Gleichung aber was ist mit LDS ?


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


(http://forum.atari-home.de/index.php?action=dlattach;topic=12775.0;attach=11507;image)
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Mi 06.07.2016, 18:31:14
LDS ist weiter oben als invertierter Eingang definiert, ebenso ist G als invertierter Ausgang definiert.

Also wird G aktiv (=low) und damit der 74HCT245 durchgeschaltet: Beim Schreiben ("/RW") immer wenn die richtige Adresse erkannt wurde; beim Lesen ("RW") aber nur, wenn auch LDS aktiv (=low) ist. Das ist immer dann der Fall, wenn auf D7-D0 Daten erwartet werden, also entweder beim Lesen eines 16-Bit-Worts oder beim Lesen eines Bytes von einer ungeraden Adresse. Da die IDE-Register alle auf ungeraden Adressen liegen, ist das grundsätzlich kein Problem.

Allerdings sehe ich nicht, warum diese Einschränkung nötig sein sollte. pperas Interface macht das nicht. Daher hatte ich es rausgenommen. LDS wird nämlich im Buszyklus erst später aktiviert und früher wieder deaktiviert als die Adresse. Ursprünglich vermutete ich dort das Timingproblem.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 06.07.2016, 20:43:41
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

Müsste das dann nicht eher so aussehen ...

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

... also alles wie im original nur ohne LDS !
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Mi 06.07.2016, 21:10:34
Nur ist RW logisch ver"oder"t mit /RW sowieso immer wahr und kürzt sich folglich heraus.

Damit ist:


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

äquivalent zu


G        =  /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 06.07.2016, 21:18:00
Ja klar ...

Das Muster zwischen denn c´t Interface und dem Teil von ppera unterscheidet sich sonst nur in der Ansteuerung der beiden 245 indem bei  ppera bei den DIR Eingängen noch AS benutzt wird. Wenn Enable "G" in Ordnung ist habe ich jetzt keine Idee mehr was falsch sein könnte ...
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am Do 07.07.2016, 09:50:07
Ist aber eigentlich logisch, den Enable nur über die Adresse zu steuern, was dann im Prinzip genau das gleiche wie das DTACK-Signal sein müsste. Und das DIR-Signal müsste RW vom Prozessor sein, höchstens vielleicht invertiert, je nach dem wie die 245er eingebaut sind.

Allerdings ist mir eins aufgefallen:
G        = LDS & RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23
       +      /RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;

Da wird LDS nur auf einer Seite des OR abgefragt.
Also werden die 245er nur aktiviert beim Lesen vom Low Byte, beim Schreiben immer.
Ich weiß aber nicht welchen Sinn das genau hat.

PS:
Hab gerade nochmal den Thread durchgelesen, genau das ist @czietz ja auch schon aufgefallen.
Ich vermute das Problem immernoch in den Chiptypen. Interessant wäre jetzt, welche genau damals in dem Bausatz dabei waren.
Das Interface das ich jetzt von @Lukas Frank bekommen habe ist mit einem 15er GAL aufgebaut. Es gibt aber auch 7,5er wie ich gesehen habe, vielleicht auch noch schnellere wenn man lange genug sucht.
Außerdem könnte ich mir vorstellen, das die vielleicht absichtlich 245er in F-Version und den 244er in LS-Version genommen haben, um dadurch zu erreichen das die Datenbits vor den Steuerbits da sind.
Dafür müsste man aber wissen was genau damals in dem Bausatz verkauft wurde.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 07.07.2016, 10:51:24
Über den Heise Vertrieb gab es damals nur die Platine und das programmierte GAL meine ich ...

Stückliste
Halbleiter
IC1    GAL20V8-20 prog.
IC2,3  74HCT245
IC4    74HCT244
D1     LED

Kondensatoren
C1     4,7 uF
C2-5   100 nF

Widerstände
R1,3,4 4k7
R2     270

Sonstiges
Platine `Ataris ST IDE-Adapter´, 2 DIL-Fassung 64pol., 2 DIL-Fassungen 32pol., doppelseitige Pin-Leisten mit 64 Pins, Pfostenstecker 40pol.

Auf dem Google Drive liegt ja der komplette Artikel "ct9309170 IDE Interface" ...
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am Do 07.07.2016, 11:04:42
Tja, dann ist es das wohl auch nicht.
Dann weiß ich auch nicht mehr weiter.

Ich denke ich warte jetzt mal auf das ppera-Interface von @neogain und hebe mir das c't-Interface für den 520er auf. Der soll intern nur eine CF-Karte bekommen und dafür brauche ich nicht wirklich Kabel. Den Rest mache ich bei dem extern.

Nur beim Mega hätte ich halt gerne etwas Kabelstrecke, damit ich eine Festplatte und ein DVD-Laufwerk unterbringen und gut positionieren kann.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am Do 07.07.2016, 11:06:14
Hallo Frank, ich hab das interface jetzt mit einem cpld nachgebildet, hab ein dev board bestellt aber ist noch nicht da. Dort hab ich alle datenleitungen mit durch den cpld geschleusst so das keine bustreiber notwendig sind. ich berichte wenn ich gegestet habe.

Hast du das Board inzwischen bekommen @tuxie ?
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Do 07.07.2016, 20:45:22
Jep ist da, werde es am Wochenende in meinen STE einbauen und Testen, habe auch schon angefangen ein layout aufzusetzen. Aber eben immer nur so wie es die Zeit zulässt.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mo 11.07.2016, 18:50:59
Bei dem Bausatz von Arne ist es ein -10ns GAL ...

Probieren wir das mal damit.
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Mo 11.07.2016, 19:07:28
Ich hatte mir wie euch per PN mitgeteilt das Listing mal angeschaut und ich denke das IOW und IOR einfach zu spät kommt da der GAL erst CS0 und CS1 generiert und dann bei LDS aktiv ist erst IOW und IOR. Laut Datenblatt muß die zweit zwischen CS0/1 und IOW/IOR um die 70NS sein. Ich hab das mal abgeändert und euch ja per PN zugesendet. Hab meinen CPLD gleich auf meinem STE drauf. Dann wird getestet.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Mo 11.07.2016, 19:25:33
Ich hatte mir wie euch per PN mitgeteilt das Listing mal angeschaut und ich denke das IOW und IOR einfach zu spät kommt da der GAL erst CS0 und CS1 generiert und dann bei LDS aktiv ist erst IOW und IOR. Laut Datenblatt muß die zweit zwischen CS0/1 und IOW/IOR um die 70NS sein.

Mindestens 70ns (im PIO-Mode 0, deutlich weniger in höheren PIO-Modes), wohlgemerkt. Ein längeres Delay zwischen CSx und IOx ist kein Problem.
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Mo 11.07.2016, 20:21:49
An irgendwas muss es aber liegen, und das ist das einzigste was anders ist zum ppera interface. Und das Funktioniert bis auf paar Kleinigkeiten recht gut (habs im STE)
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Mo 11.07.2016, 20:59:31
pperas Interface aktiviert die CS0/CS1-Leitungen beim Anliegen der Adresse:
/SELP = A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*/A5;
/SELS = A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*A5;
... und IORD/IOWD zusammen mit dem Address Strobe (/AS) des 68000:
/IORD = /AS*A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*RW;
/IOWR = /AS*A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*/RW;

Das c't-Interface aktiviert die CSx-Leitungen zum selben Zeitpunkt -- beim Anliegen der Adresse:
CS0      = /A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
CS1      =  A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
... und IORD/IOWR zusammen mit LDS:
IORD     = LDS &  RW & CS0 + LDS &  RW & CS1;
IOWR     = LDS & /RW & CS0 + LDS & /RW & CS1 [...]

LDS kommt in der Tat bei einem Schreibzyklus auf dem Bus 2 States (=125 ns @ 8 MHz) später als AS, beim einem Lesezyklus kommen sie gleichzeitig. Daher: Probiert's aus, ob das den Unterschied macht.

Den Unterschied bzgl. der Aktivierung des 74HCT245 hatten wir ja schon vorher thematisiert.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am Di 12.07.2016, 11:23:16
Also du meinst das LDS komplett ignorieren und statt dessen AS auswerten?

Mir ist noch etwas aufgefallen. Ppera erzeugt die RD/RW Signale mit der vollen Gleichung, z.B.

/IORD = /AS*A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*RW;
Aber beim c't Interface wird dafür das vorher generierte CSx-Signal verwendet:

IORD     = LDS &  RW & [b]CS0[/b] + LDS &  RW & [b]CS1[/b];
Macht das vom Timing her eventuell einen Unterschied? Nach meiner naiven Logik muss ja zuerst das eine Signal erzeugt werden, das würde bedeuten das es doppelt so lange dauert, um die RD/RW-Signale zu erzeugen.
Oder wird das vom Compiler irgendwie übersetzt?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Di 12.07.2016, 18:15:38
Also du meinst das LDS komplett ignorieren und statt dessen AS auswerten?

Ich weiß es nicht. Es ist halt ein Unterschied zwischen ppera- und c't-Interface. Wäre zu testen...

Zitat
Mir ist noch etwas aufgefallen. Ppera erzeugt die RD/RW Signale mit der vollen Gleichung, z.B.

/IORD = /AS*A23*A22*A21*A20*/A19*/A18*/A17*/A16*/A15*/A14*RW;
Aber beim c't Interface wird dafür das vorher generierte CSx-Signal verwendet:

IORD     = LDS &  RW & [b]CS0[/b] + LDS &  RW & [b]CS1[/b];

Grundsätzlich ist das ein Unterschied, ja. Aber in diesem Fall sind CS0/CS1 ja schon längst aktiv, bevor LDS low wird, d.h. das Timing von IORD hängt an LDS und nicht an den Adressbits. Dass diese durch CS0/CS1 erst etwas verzögert zur Verfügung stehen, sollte also keinen Unterschied im Timing von IORD (und IOWR) machen.
Titel: Re: c´t IDE Interface ...
Beitrag von: SolderGirl am So 17.07.2016, 15:34:10
So, heute bin ich endlich mal zum Testen gekommen. Die Ergebnisse:

1. Mit dem GAL modifiziert nach dem Vorschlag von Tuxie wird auf jedem IDE-Kanal eine Festplatte erkannt, aber nicht richtig. Statt der Modellbezeichnung wird immer der gleiche unsinnige String angezeigt. Sowohl mit als auch ohne 245er. Nur der String ändert sich.

2. Mit dem GAL modifiziert nach dem Vorschlag von czietz passiert mit 245er das gleiche wie beim original: Die Platte und die Partitionen werden erkannt, aber es gibt immer wieder Datenfehler. Ohne 245er wird die Platte erkannt, aber sobald TOS versucht darauf zuzugreifen (noch bevor der Desktop erscheint) bleibt der Rechner bombig hängen.

3. Beim original GAL macht es keinen Unterschied, ob es der 15ns oder 10ns Baustein ist. Beide funktionieren ohne 245er problemlos, mit 245er funktioniert nurnoch die Erkennung, aber Datenfehler beim lesen und/oder schreiben.

Ich denke ich warte bis ich ein BitScope habe und messe dann mal wirklich das Timing genau durch.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 30.07.2016, 12:10:20
Ich bin sehr gespannt auf das Ergebnis ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 12:42:44
Habe noch ein wenig probiert und möchte gerne minimal neben dem IDE Interface was ja läuft ohne die beiden Bustreiber die TOS 2.06 Option ans funktionieren bekommen was sie nicht tut ...

*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 + LDS &  RW & CS1;
     
IOWR     = LDS & /RW & CS0 + LDS & /RW & CS1 + LDS & /RW & TOS; % Signal TOS wegen EEPROMs %

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

*END

Habe geändert in ...

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

geht auch nicht ! und geändert in ...

TOS      = ROM2
   + AS & A23 & A22 & A21 & /A20 & /A19 & /A18 & RW;

geht auch nicht ! und geändert in ...

TOS      = /ROM2
   + /AS & A23 & A22 & A21 & /A20 & /A19 & /A18 & RW;

... geht auch nicht !

Ich habe keine Idee mehr warum der Rechner das TOS 2.06 von der Erweiterung nicht bootet !?!

Etwas seltsam die Beschaltung mit A18 doppelt und beim EE Eprom mit A19. Aber das ganze sollte doch nichts machen bei 27C010 Eproms, oder ?

D8 -D15 = EE Eprom Hi
D0 - D7 = E0 Eprom Lo
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am So 19.03.2017, 13:27:52
Also,

eingangs wird Rom2 und AS auf Low Aktiv gesetzt, also sollte es so funktionieren

TOS      = ROM2
        + AS & A23 & A22 & A21 & /A20 & /A19 & /A18 & RW;

Pass mal dein DTACK Signal an, da ist /A17 zu viel...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 19.03.2017, 13:35:56
Alte ROMs aus dem Rechner vorher ausgebaut?

Pass mal dein DTACK Signal an, da ist /A17 zu viel...

Wie man's nimmt, die Zeile "/A17 & /A18 & /A19 & A20 & A21 & A22 & A23" ist ja sowieso für's IDE-Interface, da stört das /A17 nicht weiter, für TOS-Zugriff wird DTACK ja auch erzeugt.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 14:11:40
Funktioniert nicht ...


-------
Datei "C:\ALT\JEDI.045\CT_IDE_2.LCI" gelesen.
LOG-Datei von JEDI, Version 0.45
JEDI ist ein Shareware-Programm von
  Ralf Zimmermann
            ___  ___
           |   \/   |
        A5 |1     24| VCC       
     !ROM2 |2     23| IRQ14     
       !AS |3     22| !IOWR     
      !LDS |4     21| !IORD     
        RW |5     20| !TOS     
       A17 |6     19| !INT     
       A18 |7     18| !CS1     
       A20 |8     17| !CS0     
       A19 |9     16| !G       
       A21 |10    15| !DTACK   
       A22 |11    14| !IOCHRDY 
       GND |12    13| A23       
           |________|

' OLMC 0:
 IOWR.OE      = VCC;
 IOWR         = LDS * !RW * CS0
              + LDS * !RW * CS1
              + LDS * !RW * TOS;
' OLMC 1:
 IORD.OE      = VCC;
 IORD         = LDS * RW * CS0
              + LDS * RW * CS1;
' OLMC 3:
 INT.OE       = IRQ14;
 INT          = IRQ14;
' OLMC 4:
 CS1.OE       = VCC;
 CS1          = A5 * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 5:
 CS0.OE       = VCC;
 CS0          = !A5 * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 6:
 G.OE         = VCC;
 G            = LDS * RW * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23
              + !RW * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 7:
 DTACK.OE     = !IOCHRDY * AS * !A19 * A21 * A22 * A23;
 DTACK        = !A18 * !A19 * A20 * A21 * A22 * A23
              + TOS;

----------------------------------------------------------------------
Gew„hlter GAL-Modus:  Mode2, Tristate
----------------------------------------------------------------------
----------------------------------------------------------------------
Assemblier-Vorgang erfolgreich beendet
----------------------------------------------------------------------


JEDI gibt nichts aus für die Pin20 TOS welches das /CE Signal sein sollte für die beiden Eproms. Mit dem Multimeter gemessen ist der Pin20 auch Dauerhaft high ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 19.03.2017, 14:31:49
Da TOS schon benutzt wird (z.B. in der Gleichung von DTACK), bevor es definiert wird, beschließt JEDI wohl, das sei ein Eingang und ignoriert die Zuweisung weiter unten. Aus meiner Sicht ein Bug, es sollte zumindest eine Warnung kommen. Wer weiß, welche Bugs noch alle in JEDI stecken...

Pack mal die Zeile "TOS = ..." vor die Zeile "DTACK = ...".

Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 15:13:25
Sieht schon besser aus ...

-------
Datei "C:\ALT\JEDI.045\CT_IDE_2.LCI" gelesen.
LOG-Datei von JEDI, Version 0.45
JEDI ist ein Shareware-Programm von
  Ralf Zimmermann

            ___  ___
           |   \/   |
        A5 |1     24| VCC       
     !ROM2 |2     23| IRQ14     
       !AS |3     22| !IOWR     
      !LDS |4     21| !IORD     
        RW |5     20| !TOS     
       A17 |6     19| !INT     
       A18 |7     18| !CS1     
       A20 |8     17| !CS0     
       A19 |9     16| !G       
       A21 |10    15| !DTACK   
       A22 |11    14| !IOCHRDY 
       GND |12    13| A23       
           |________|

' OLMC 0:
 IOWR.OE      = VCC;
 IOWR         = LDS * !RW * CS0
              + LDS * !RW * CS1
              + LDS * !RW * TOS;
' OLMC 1:
 IORD.OE      = VCC;
 IORD         = LDS * RW * CS0
              + LDS * RW * CS1;
' OLMC 2:
 TOS.OE       = VCC;
 TOS          = ROM2
              + AS * A23 * A22 * A21 * !A20 * !A19 * !A18 * RW;
' OLMC 3:
 INT.OE       = IRQ14;
 INT          = IRQ14;
' OLMC 4:
 CS1.OE       = VCC;
 CS1          = A5 * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 5:
 CS0.OE       = VCC;
 CS0          = !A5 * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 6:
 G.OE         = VCC;
 G            = LDS * RW * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23
              + !RW * !A17 * !A18 * !A19 * A20 * A21 * A22 * A23;
' OLMC 7:
 DTACK.OE     = !IOCHRDY * AS * !A19 * A21 * A22 * A23;
 DTACK        = !A18 * !A19 * A20 * A21 * A22 * A23
              + TOS;

----------------------------------------------------------------------
Gew„hlter GAL-Modus:  Mode2, Tristate
----------------------------------------------------------------------
----------------------------------------------------------------------
Assemblier-Vorgang erfolgreich beendet
----------------------------------------------------------------------

Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 15:15:31
Da fehlt jetzt aber INIT ...
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 15:20:03
Gibt es denn einen guten GAL Assembler als freie Software unter Windows ?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 19.03.2017, 15:20:36
INIT? Meinst Du INT? Das ist doch da, in Output Logic Macrocell Nr. 3.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 19.03.2017, 15:42:21
Gibt es denn einen guten GAL Assembler als freie Software unter Windows ?

Freie Software? Keine, der mir bekannt wäre. Kostenlos, ja klar, aber frei wie in "Freiheit"? GALs sind in den letzten 20 Jahren etwas außer Mode gekommen, sodass die Menge an aktueller Software, die sie unterstützt, eher klein ist.

Atmels WinCUPL soll dem Vernehmen nach auch GALs unterstützen. Dann natürlich ispLEVER classic von Lattice, dem ehemaligen Hersteller der GALs. Allerdings fand ich es bei ispLEVER classic etwas übertrieben, 1 GB Software herunterzuladen, inkl. Synthesetools für VHDL und Verilog, nur um ein GAL zu programmieren. Daher habe ich mit keinem der genannten Programme eigene Erfahrung.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 19.03.2017, 15:47:30
JA war blind INIT ist natürlich da. Geht aber auch jetzt nicht mit den Änderungen von tuxie und original ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am So 19.03.2017, 18:56:19
Grundsätzlich sieht das Log von JEDI jetzt aber gut aus, wenn die Software auch alles so implementiert, wie im Log geschrieben. Da IDE ja offensichtlich geht, können wir auch ein defektes GAL mehr oder weniger ausschließen. Siehst Du denn mit dem Scope nach dem Reset Low-Pulse auf TOS und DTACK am GAL?

EDIT: OK, das Problem mit der ursprünglichen Datei ist der Kommentar "% Signal TOS wegen EEPROMs %", der JEDI verwirrt. Nimmt man ihn weg, wird auch das File in der ursprünglichen Reihenfolge korrekt assembliert. Das Kommentarzeichen laut JEDI-Hilfe ist auch ' und nicht %, aber dennoch würde ich immer noch einen Syntax-Error in der Zeile mit Kommentar erwarten. Oder zumindest eine Fehlermeldung, wenn dem vermeintlichen Input /TOS plötzlich ein Ausgabewert zugewiesen wird.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 24.03.2017, 17:54:10
Klappt alles nicht. Ich habe noch mal die Eproms nachgemessen und dort stimmt alles. Das GAL CS2 Bild ist vom original GAL und das 3 mit /A18 und RW ...
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Fr 24.03.2017, 18:18:13
Was ist den überhaupt Clock und CE in Deinen Screenshots? Ich wollte ja die Ausgänge TOS und DTACK Deines GALs sehen.

Wenn ist jetzt mal rate und Clock der Systemtakt sein sollte, warum folgt CE (was auch immer das ist) denn dem Systemtakt? Keiner der GAL-Ausgänge hängt vom Systemtakt ab.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 24.03.2017, 18:30:25
CE ist der CE Anschluss der beiden Eproms und somit der TOS Ausgang vom GAL.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 24.03.2017, 18:45:16
Ich messe da nur Mist !
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Fr 24.03.2017, 19:06:28
Hat der Logikanalyzer auch richtigen Kontakt? Ich kenne das Verhalten, dass ein Kanal (bei Dir CE) scheinbar mehr oder weniger einem anderen (bei Dir Clock) folgt, wenn ersterer Kanal offen ist und sich durch kapazitive Kopplung Signale von zweiterem Kanal einfängt. Komisch werden die Signal auch, wenn die Masse nicht richtig verbunden ist.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Fr 24.03.2017, 20:31:40
Ich lege das erstmal alles weg. Habe die Nase voll ...
Titel: Re: c´t IDE Interface ...
Beitrag von: guest3943 am Do 29.06.2017, 11:41:08
Hallo Zusammen,

Gestern Nacht bin ich über diese Seite gestolpert und das hat viele Erinnerungen geweckt.
Schade dass ihr das Interface nicht mehr zum Leben erwecken konntet. Ich erinnere mich, dass es damals einige Zeit brauchte, bis ich das Timing richtig hinbekommen hatte. Damals versuchte ich auch mit verschiedenen Logic-Typen, aber die HCTs waren die richtigen für diese Aufgabe. Das Timing wurde im wesentlichen durch das GAL erzeugt. Hier war wichtig zu verstehen, wie der GAL Compiler das genau umgesetzt hatte. Das Listing alleine gibt das glaube ich nicht so eindeutig wieder, aber so genau erinnere ich mich nicht mehr daran. Das originale Programmierfile liegt mir leider nicht mehr vor... die eMedia hatte die Entwicklung des PCBs mit dem Verkauf der Platine und des programmierten GALs finanziert.

Das ganze lief in meinem "aufgebohrten" 520ST, den ich mit Blitter, IDE und PAK(2?, 68020?), 1MB RAM aufgerüstet hatte. Ich weiss noch genau wie ich mein erstes Geld aus der Lehre in die RAMs investierte und als die Bausteine per UPS ankamen, hatte ich mich gleich krank gemeldet und den Lötkolben eingeschaltet.

Damals hatte ich das IDE Interface glaube ich mit Quantum 100MB Platten betrieben. Zum identifizieren der Platte wird glaube ich nur PIO angesprochen, der Datenaustausch lief dann eventuell über DMA, dafür könnte das LDS Signal wichtig gewesen sein... zumindest erinnere ich mich, dass es verschiedene Zugriffsarten gab, die abgebildet werden mussten. Danach habe ich mich hauptsächlich mit der Optimierung der IDE Zugriffe auf der Softwareseite beschäftigt (das nannte ich damals TurboIDE und experimentierte mit Blitter als DMA Controller und Multiple-Sektor-Read). Damals reizte es das IDE Interface der Festplatten aus, mehr ging da nicht zu holen.

Viele Spass und Erfolg,
Kai  8)
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 29.06.2017, 13:11:45
Vielleicht sollte man es mit dem ursprünglichem GAL Assembler mal versuchen.

So ein schönes Teil, wäre schade drum ...
Titel: Re: c´t IDE Interface ...
Beitrag von: joejoe am So 02.07.2017, 08:41:13
Falls der ursprünglich GAL Assembler PALASM hieß, dann kann ich hier meine Files beisteuern:
Offenbar habe ich die Listings damals abgetippt, da sich in den PDS-Files keine Copyrights finden.
Ganz korrekte Zeitgenossen mögen diese bitte ergänzen ;)

Im zip.pdf stecken zwei Varianten; einmal die "normale" und einmal eine Variante ohne TOS-CARD Funktion, z.B. für eine PAK, ganz hilfreich.

Vielleicht hilft es ja weiter...

Edit:
Die Compilate (*.jed) von damals sind natürlich auch dabei!
Ich kann mich allerdings auch an irgendwelche Probleme mit dem Interface erinnern, hatte auch mit verschiedenen Logik-Familien experimentiert.
Kann sein, dass die Variante ohne TOS-EPROMs auch unter diesem Aspekt entstanden war.
Im Zusammenspiel mit einer PAK und 32bit EPROMs ist die TOS-Card Opition auch obsolet.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 02.07.2017, 10:13:26
@kscheff ... war es denn Palasm als Assembler ?

-------------------------------
// 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
------------------------------------
Im Listing steht leider nichts.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 02.07.2017, 14:25:59
@joejoe ... erstaunlich mit dem Palasm JED funktionieren die beiden HCT245 Bustreiber jetzt. Wunderbar ...

Was nicht geht ist das TOS 2.06 auf der Karte. Verdrahtungsfehler schliesse ich mal aus. Hatte das schon mehrmals geprüft. Unsicher bin ich im Schaltplan mit A18 und A19 an dem Eprom Sockeln ...
Titel: Re: c´t IDE Interface ...
Beitrag von: joejoe am So 02.07.2017, 16:14:47
Du nutzt das Teil aber nicht zusammen mit einer PAK? oder?
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 02.07.2017, 16:17:52
Ne zur Zeit ein normaler Atari Mega ST ...

Geht aber auch mit PAK.
Titel: Re: c´t IDE Interface ...
Beitrag von: joejoe am So 02.07.2017, 16:32:22
ja, das mag gehen,
wäre aber ziemlich sinnlos, wenn das TOS dann doch auf der PAK sitzt.
Die beiden ROMs wären nur für die ersten 8 Byte zuständig und das rom2 Signal von der GLUE wird auch noch fehlerträchtig "durchs GAL geschleift". Von Vorteil ist natürlich, dass so ein einfacher Wechsel von TOS 2.06 mit 68000 CPU zum TOS 3.06 mit 68020/68030 möglich ist.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am So 02.07.2017, 16:35:27
... wäre aber ziemlich sinnlos ....

Ist schon klar, man muss es ja nicht nutzen.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Di 13.11.2018, 18:27:52
So der Stand ist jetzt so das die beiden HCT245 Treiber Bausteine funktionieren. Ich habe noch an deren Ausgänge in Reihe 47 Ohm Widerstände. Da das ganze mit dem TOS auf der Platine nicht mehr funktionierte wegen dem Layout ist das TOS jetzt extern. Man kann TOS 2.06 nutzen oder auch EmuTOS in der 256kB Version.

Zudem kann man auch nur die Adapter Platinchen nutzen um TOS 1.04 in zwei 27C010 Eproms als zwei Chip Version einzusetzen.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Di 13.11.2018, 22:10:04
Sehr cool ... entspricht genau dem, was ich meinem Mega1 noch verpassen wollte (nach TOS 1.04, 4MB und HD Modul).
Ich setz mich die Tage dann mal an ein Layout mit SMD, so dass bis auf den IDE Stecker alles unter die CPU passt.
Titel: Re: c´t IDE Interface ...
Beitrag von: Meru am Mi 14.11.2018, 10:57:33
Hallo,

Weis jemand wo man den vollständigen Artikel der c‘t herbekommen kann?
 

Mfg Meru
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Mi 14.11.2018, 11:10:22
Gegenüber dem was demnächst kommt, braucht es das nicht mehr ;) und glaubt mir es will jeder haben  :D..

Thunder meets Lighnting 000
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 14.11.2018, 12:11:06
Bin gespannt, will ein IDE + USB für den ST haben wollen ...
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Mi 14.11.2018, 23:21:01
Zwischenstand für heute:
Titel: Re: c´t IDE Interface ...
Beitrag von: ari.tao am Do 15.11.2018, 00:56:36
Paßt das denn in einen 1040er?
Könntest Du nicht gleich ein ´Monster´ bauen?
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Do 15.11.2018, 08:38:59
Respekt, schön klein. Das hätte ich in Eagle nicht hinbekommen.

Titel: Re: c´t IDE Interface ...
Beitrag von: Arthur am Do 15.11.2018, 17:15:35
Dem stimme ich voll zu...schön kompakt... das passt fast überall.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Fr 16.11.2018, 10:38:05
Fast fertig ...
fehlen noch 2 Signale, das finale entzerren der Groundplane und etwas Aufräumarbeit.

In den meisten STs und STEs (mit Adapter) sollte die Platine passen, sicher kann ich das aber nicht sagen, da ich vermutlich nicht alle Revisionen 'auf dem Schirm' habe. Bei STs bei denen die CPU unten mittig sitzt (z.B.: C103175) kann ich mir durchaus vorstellen, dass es nach oben zur Tastatur knapp werden kann. Bei Rev. C070789 kanns sein, dass einer der Stege für die Floppy angepasst werden muss. Mit den ganzen WRS Erweiterungen sollte es passen (werd ich aber nochmal sicher abgleichen ... PAK68/3 und FRAK/2 sind beim aktuellen Stand evtl. was fummelig).

RAM oder 'nen 2. IDE Kanal wollte ich eigentlich nicht draufpacken. Insgeheim gehts mir auch primär darum meinen Mega1 auf TOS 2.06 umzurüsten und zu gucken ob meine 'DiskOnModule"-Module von pqi mit der Schaltung laufen.
Persönliche Zielsetzung ist wie gesagt Mega1 sowie ein 1040STE im DDD-Desktop Gehäuse.
Titel: Re: c´t IDE Interface ...
Beitrag von: ari.tao am Fr 16.11.2018, 11:47:35
Nun ja, ich melde da schon mal vorsichtig mein Interesse an, für meinen STe, für den Fall, daß es doch keine Monster mehr dafür gibt.
Verträgt sich Dein IDE-Adpt. zB. auch mit dem STe-Beschleuniger von exxos?
Titel: Re: c´t IDE Interface ...
Beitrag von: tuxie am Fr 16.11.2018, 11:52:31
Der STE hat eine PLCC CPU ;)

Und ja die Lightning ST mit USB und IDE Interface welches wie die  Thunder SmartSwap unterstützt, ist greifbar nahe.. denke zu Weihnachten werden die ersten Prototypen laufen. Diese hat natürlich sehr viele Features da der Datenbus durch einen CPLD geschleift ist und natürlich dann auch mit richtigen Timing.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Fr 16.11.2018, 15:56:35
Interesse ankündigen bringt bei mir nix ;)
Sobald ich verifiziert hab, dass das Layout läuft (bin da recht zuversichtlich, ich mach ja nix anders als Lukas Frank) werd ich die Gerber Files und 'ne Kurzanleitung unter 'ner CC-Lizenz hochladen - Produktion und eventuelle Verbesserungen/Erweiterungen sind dann der Community überlassen ;)
Überproduktion beim Testlauf (also Platinen die ich übrig haben werde) sind ziemlich unwahrscheinlich.

Ich will hier auch nix loslassen, was als "Konkurrenz" zur LightningST gesehen werden könnte ... hier das is eher nützliches Alteisen und ggf. Motivation für den einen oder anderen sich mit Schaltplänen oder Gerber Files auseinander zu setzen ... oder Spaß an 'ner klassischen 'Minimallösung' zu haben (die optional ein TOS 2.06 mitbringt). Meine Motivation is da eher Spaß am layouten und dass die Lösung ziemlich meinem aktuellen Bedarf entspricht.
Grade mit dem USB Support dürfte die LightningST einen ziemlichen Mehrwert haben, wo hier die Karte nicht mithalten kann.

EDIT: Layout für den IDE Teil fertig, jetzt kommen noch die TOS 2.06 Sockel
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 17.11.2018, 16:43:30
Kann mir wer erklären was das mit den Adressleitungen an den VPP Pins von den (Flash-)ROMs soll?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Sa 17.11.2018, 16:49:52
Kann mir wer erklären was das mit den Adressleitungen an den VPP Pins von den (Flash-)ROMs soll?

Kannst Du in einem Screenshot zeigen, worauf genau sich Deine Frage bezieht?
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 17.11.2018, 17:02:53
Kann mir wer erklären was das mit den Adressleitungen an den VPP Pins von den (Flash-)ROMs soll?

Kannst Du in einem Screenshot zeigen, worauf genau sich Deine Frage bezieht?
Bezieht sich auf den Schaltplan den Lukas Frank hier verlinkt hatte: https://forum.atari-home.de/index.php/topic,12775.msg215790.html#msg215790
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Sa 17.11.2018, 18:05:39
Das verstehe ich auch nicht.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 17.11.2018, 18:28:49
Ist es nicht unnötig bei 1 mal TOS wie 2.06 in 27C010 oder umschaltbar EmuTOS <-> 2.06 mit einem 27C020, oder ?
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 17.11.2018, 18:47:03
Ah, habs verstanden ... beim 29F040 is dort die höchste Adressleitung.
27C020 bzw. 27C010 würde mir eigentlich auch reichen ... hab hier allerdings knappe 10 Flashroms in passender Größe rumfliegen von daher, wieso nicht? Prinzipiell reichen mir 2 Bänke - einmal TOS 2.06 und einmal 1.04 für'n Mega1

EDIT: Layout is quasi fertig (ROM Adapter wollte ich nochmal mit Verstand angucken und die Belegung vom Header is noch nicht ganz richtig)

EDIT2: Layout und Schaltplan sind durch - allerdings hab ich mich grade entschieden die gerber Files doch nicht öffentlich zu machen und lieber vielleicht irgendwann mal fertige Platinensätze für 2000% Gewinn auf eBay zu kloppen (oder im kleinen Kreis zum fairen Preis zu verteilen ... sorry).
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 12:51:57
Was brauch ich denn an Software damit ich die Karte nutzen kann?
Hab hier 'nen Mega4 mit TOS 1.04 oder KAOS 1.4.3 und weder mit HDDriver (7.x/8.x) oder AHDI 6.0 komm ich weiter.
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Sa 22.12.2018, 13:20:17
TOS 1.04 kann nicht von IDE booten, aber von Diskette gestartet werden AHDI und HDDRIVER Deine IDE-Geräte finden. Falls nicht, ist ein Fehler im Layout oder beim Zusammenbau passiert.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 13:34:41
Jut ... dann mach ich mich mal an die Fehlersuche.
Das mit'm booten war mir bekannt ... hab jetzt auch festgestellt, dass die TOS 2.06 Geschichte aus der c't nicht läuft.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 22.12.2018, 14:12:16
... hab jetzt auch festgestellt, dass die TOS 2.06 Geschichte aus der c't nicht läuft.

Doch das mit dem TOS 2.06 läuft. Meine ersten zwei Layouts hatten Probleme und es lief nicht, auch gingen die HCT245 Treiber nicht. Mit dem dritten Layout läuft jetzt alles. Habe mir auch einen Wolf gesucht und nichts finden können ...
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 15:04:59
Was hast'n du beim 3. Layout anders gemacht?
Einen Fehler hab ich gefunden ... bei mir sind die Adressleitungen A19 und A20 am GAL vertauscht. Pins zu tauschen hat allerdings nichts gebracht. Nur um wirklich sicher zu sein, Pin1 am GAL ist A5 und nicht AS, richtig?
Titel: Re: c´t IDE Interface ...
Beitrag von: czietz am Sa 22.12.2018, 15:25:47
Was hast'n du beim 3. Layout anders gemacht?
Einen Fehler hab ich gefunden ... bei mir sind die Adressleitungen A19 und A20 am GAL vertauscht. Pins zu tauschen hat allerdings nichts gebracht. Nur um wirklich sicher zu sein, Pin1 am GAL ist A5 und nicht AS, richtig?


Ja, das passt auch zum den GAL-Gleichungen, die Frank in https://forum.atari-home.de/index.php/topic,12775.msg219235.html#msg219235 gepostet hat.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 22.12.2018, 15:49:07
Was hast'n du beim 3. Layout anders gemacht?

Habe keine Ahnung. Ich hatte auch mal mit der Sortierung beim GAL gespielt und da ging was, was zuvor nicht ging. Ich war aber zu chaotisch und weiss nicht wie und was war. Timing Geschichte vermute ich wenn in der Schaltung/Layout kein Fehler ist.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 15:59:23
Is mir dann auch kurz nach dem Post eingefallen dort mal nachzugucken.
Hmpf ... dann schau ich mal weiter.

.jed Dateien hab ich die von joejoe genommen.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Sa 22.12.2018, 16:01:57
Ich nehme die originale ...
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 17:12:41
Läuft auch damit nicht ... die ROM-Frickelei is jetzt auch erstmal in die Tonne geflogen und bau ich erst wieder auf wenn der IDE Teil läuft.
wenn wer von euch rausfindet worans liegt, gibt's nen Platinensatz geschenkt. Schaltplan is im Anhang (Pins 8 & 9 am GAL hatte ich schon gefunden).
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 17:40:39
Nochmal 2 gefunden ... R1 und R3 gehören an VCC, nicht an Masse.

EDIT: Nu wird die Festplatte auch erkannt.
Titel: Re: c´t IDE Interface ...
Beitrag von: shock__ am Sa 22.12.2018, 19:50:56
Nur das TOS will noch nicht so ganz ... Bootloop mit 3 Bomben und nem schwarzen Block wo eigentlich das Atari Logo sein sollte. Liegt aber vielleicht daran, dass ich die Verdrahtung von UDS/LDS an den ROMs verkackt hab.
Aber schonmal 3 Ecken besser als vorher ... da gabs nämlich gähnende Leere, sprich garnichts.

EDIT: Läuft jetzt auch mit der richtigen Verdrahtung ... jetzt muss ich mich nur nochmal in HDDriver einlesen. Controller wird als Milan IDE erkannt und die Festplatte hat auch 'ne korrekte ID, allerdings hab ich keine Auswahl im Formatier/Partitionier-Menü.
EDIT2: DOM war als Slave gejumpert, jetzt als Master läufts problemlos.
EDIT3: Und das obligatorische Beweisfoto vom Aufbau ... is zwar leider etwas chaotischer geworden als gedacht, aber _eigentlich_ isses ja auch nur ein Prototyp ... von daher darf das so ;)
Titel: Re: c´t IDE Interface ...
Beitrag von: Megatari am Mi 13.10.2021, 15:17:25
Sobald ich verifiziert hab, dass das Layout läuft (bin da recht zuversichtlich, ich mach ja nix anders als Lukas Frank) werd ich die Gerber Files und 'ne Kurzanleitung unter 'ner CC-Lizenz hochladen
Ich bin daran interessiert. Gibt es einen Link?
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 13.10.2021, 15:26:08
c´t  Ausgabe 09/1993 Seite 170

Warum baust du nicht das einfache Interface von P. Putnik ?
Titel: Re: c´t IDE Interface ...
Beitrag von: Megatari am Mi 13.10.2021, 15:29:59
c´t  Ausgabe 09/1993 Seite 170

Warum baust du nicht das einfache Interface von P. Putnik ?
Das ist etwas eigensinng und hakt manchmal.
 
Daher wollte ich jetzt mal das aus der c't probieren.
In dem c't Schaltplan sind keine Widerstände in den Datenleitungen eingezeichnet. Auf euren Platinen sind welche drin.

Ich denke mal, dass das c't Interface stabiler läuft.
Titel: Re: c´t IDE Interface ...
Beitrag von: Lukas Frank am Mi 13.10.2021, 15:41:07
Unterhalte dich mal mit @neogain ... so weit ich weiss hat er das ppera Interface schon einige Male nachgebaut ohne Probleme. Es gibt das auch in verschiedenen Versionen z.B. von Popsel und von ppera für den Mega ST Bus ...