atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet 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 ?
-
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 abgendert
GAL-Listing fr 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 fr 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 ...
-
Du könntest -- zumindest, um zu sehen, was passiert -- beim Heise-Verlag reklamieren. Immerhin hast Du für einen Artikel mit lesbaren Grafiken bezahlt.
-
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 ...
-
Ich bezweifel das die diese Alten Ausgaben in besserer Qualität haben. Hab das auch schonmal gekauft und sehr unleserlich.
-
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.
-
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 ...
-
Die PDFs sind gut... wie eine original C't nur als PDF... aber der HTML-Dreck von 1990-2003 geht gar nicht... :-[
-
Habe den Scan in guter Qualität, löte das Teil auch schon zusammen ...
-
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)
-
Das ist schon ein sehr schönes Teil. Vielleicht überwinde ich mich mal versuche mich doch mal an einer Platine in Eagle, mal schauen ...
-
Sind die Treiber-ICs denn jetzt da? Oder läuft's ohne Treiber stabil?
-
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 ...
-
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ß
-
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.
-
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.
-
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 ...
-
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 ...
-
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.
-
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 ?
-
Wenn du mir den Schaltplan mal zusenden könntest dann kann ich ihn mir nochmal anschauen und das GAL Listing vergleichen.
-
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...)
-
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.
-
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.
-
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.
-
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.
-
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 ?
-
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.
-
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
-
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.
-
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".
-
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.
-
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 ...
-
Das GAL nach der Idee von czietz ist auf dem Weg, mal schauen ob es damit geht oder nicht ...
Ich bin gespannt.
-
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.
-
@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 ?
-
@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.
-
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.
-
@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 : 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.
-
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 !
-
... 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.
-
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...
-
Ich vermute mal mit der Platte hat das wenig zu tun. Ich hatte das mit CF Karte, eine alte mit 512MB.
-
Was ich meinte war Mint. Daher die bedenken
-
Was hat ein IDE Interface mit MiNT zu tun ?
-
Was hat ein IDE Interface mit MiNT zu tun ?
Braucht Mint nicht HDDriver? oder bringt Mint seine eigenen Treiber mit?
-
Mint liegt im Autoordner und da wurde HDDriver ja schon geladen also ja Mint braucht auch einen HD-Driver.
-
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.
-
MiNT hat mit einem bestimmten Plattentreiber erstmal nichts zu tun. Da kann auch der AHDI oder der von ppera benutzt werden oder sonst was ...
-
"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)
-
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.
-
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 !
-
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;
-
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 ...
-
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.
-
Ü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" ...
-
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.
-
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 ?
-
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.
-
Bei dem Bausatz von Arne ist es ein -10ns GAL ...
Probieren wir das mal damit.
-
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.
-
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.
-
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)
-
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.
-
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?
-
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...
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.
-
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.
-
Ich bin sehr gespannt auf das Ergebnis ...
-
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
-
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...
-
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.
-
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;
----------------------------------------------------------------------
Gewhlter 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 ...
-
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 = ...".
-
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;
----------------------------------------------------------------------
Gewhlter GAL-Modus: Mode2, Tristate
----------------------------------------------------------------------
----------------------------------------------------------------------
Assemblier-Vorgang erfolgreich beendet
----------------------------------------------------------------------
-
Da fehlt jetzt aber INIT ...
-
Gibt es denn einen guten GAL Assembler als freie Software unter Windows ?
-
INIT? Meinst Du INT? Das ist doch da, in Output Logic Macrocell Nr. 3.
-
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.
-
JA war blind INIT ist natürlich da. Geht aber auch jetzt nicht mit den Änderungen von tuxie und original ...
-
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.
-
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 ...
-
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.
-
CE ist der CE Anschluss der beiden Eproms und somit der TOS Ausgang vom GAL.
-
Ich messe da nur Mist !
-
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.
-
Ich lege das erstmal alles weg. Habe die Nase voll ...
-
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)
-
Vielleicht sollte man es mit dem ursprünglichem GAL Assembler mal versuchen.
So ein schönes Teil, wäre schade drum ...
-
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.
-
@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.
-
@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 ...
-
Du nutzt das Teil aber nicht zusammen mit einer PAK? oder?
-
Ne zur Zeit ein normaler Atari Mega ST ...
Geht aber auch mit PAK.
-
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.
-
... wäre aber ziemlich sinnlos ....
Ist schon klar, man muss es ja nicht nutzen.
-
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.
-
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.
-
Hallo,
Weis jemand wo man den vollständigen Artikel der c‘t herbekommen kann?
Mfg Meru
-
Gegenüber dem was demnächst kommt, braucht es das nicht mehr ;) und glaubt mir es will jeder haben :D..
Thunder meets Lighnting 000
-
Bin gespannt, will ein IDE + USB für den ST haben wollen ...
-
Zwischenstand für heute:
-
Paßt das denn in einen 1040er?
Könntest Du nicht gleich ein ´Monster´ bauen?
-
Respekt, schön klein. Das hätte ich in Eagle nicht hinbekommen.
-
Dem stimme ich voll zu...schön kompakt... das passt fast überall.
-
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.
-
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?
-
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.
-
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
-
Kann mir wer erklären was das mit den Adressleitungen an den VPP Pins von den (Flash-)ROMs soll?
-
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?
-
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
-
Das verstehe ich auch nicht.
-
Ist es nicht unnötig bei 1 mal TOS wie 2.06 in 27C010 oder umschaltbar EmuTOS <-> 2.06 mit einem 27C020, oder ?
-
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).
-
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.
-
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.
-
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.
-
... 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 ...
-
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?
-
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.
-
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.
-
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.
-
Ich nehme die originale ...
-
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).
-
Nochmal 2 gefunden ... R1 und R3 gehören an VCC, nicht an Masse.
EDIT: Nu wird die Festplatte auch erkannt.
-
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 ;)
-
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?
-
c´t Ausgabe 09/1993 Seite 170
Warum baust du nicht das einfache Interface von P. Putnik ?
-
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.
-
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 ...