atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: ToPeG am Mi 14.12.2011, 01:59:55
-
Als ich vorhin Im BIOS meines PC ein paar Sachen neu eingestellt habe, fiel mir der Parallelort ins Auge und das er dank ECP/EPP auch Bidirektional betrieben werden kann.
Zuerst dachte ich man könnte damit den ACSI-Festplatten am PC betreiben. Aber zu fehlt genau eine ausgehende Signalleitung. Aber ich denke ich habe da schon eine Idee... :)
Aber was möglich ist den PC als Device an den Atari zu hängen. Damit ist eine Festplattensimulation möglich.
Ich habe einen kleinen Schaltplan gemacht das die Parallelport Signale mit den ACSI Signalen verbindet. Die Verkabelung ist nicht kompliziert und völlig passiv.
Was natürlich noch fehlt ist die Software zur Festplattensimulation.
Möglicherweise finde ich nach Weihnachten ein paar Tage Zeit das Kabel zusammen zu löten und ein kleines Testprogramm zu schreiben. Ich dachte da an eine Megafile Emulation über ein HDD-Image. Mal schauen. :)
-
GhostLink über Parallelport wäre fein. Aber ob man an die Sourcen kommt?
-
Wow, bist Du ein Zauberer oder so etwas?
Beschreib mal bitte, wie Du so etwas programmierst. Also: wie gehst Du da ran mit welchen Überlegungen, welche Programme nutzt Du, welche Programmiersprache.
Mit Programmierung kenne ich mich nun überhaupt nicht aus, muss ich zugeben.
Übrigens sucht der gute Mr. Smile noch immer einen Mentor; er will das Programmieren auf dem Atari erlernen.
VG Gaga
-
OT:
Übrigens sucht der gute Mr. Smile noch immer einen Mentor; er will das Programmieren auf dem Atari erlernen.
Er könnte Omikronman fragen, der würde ihn in Omikron Basic einführen.
-
Mr. Smile hat ja hier schon vor einiger Zeit öffentlich gefragt, ohne eine ernsthafte Antwort darauf zu bekommen. Ich hatte für mich leider das Gefühl, dass es etwas ins Lächerliche gezogen wurde. Schade irgendwie, denn da ist jemand, der will und sind auch Leute, die können, aber....
http://forum.atari-home.de/index.php?topic=8874.msg61459;boardseen#new
Er sucht jemand, der fit in ASSEMBLER ist.
-
Auf dem Atari müsste erst mal nichts Programmiert werden. Sofern ordentlich umgesetzt sollte jeder Festplattentreiber den PC als Festplatte erkennen.
Auf dem PC müsste ich (oder jemand anderes der darin Erfahrung hat) in C oder ähnlichem eine ACSI-Festplatte simulieren. Das sollte nicht so kompliziert sein, da die Megafiles z.B. nur vier Basis-Befehle (EDIT: 8 oder so insgesamt) kennen. Zudem kenne ich mich mit dem ACSI Bus und Protokoll etwas aus. Ich sehe keine Unüberwindlichen Hürden, so was zu implementieren.
Ich würde es bei mir zuerst auf Linux Programmieren, da ich mich damit am besten auskenne und der direkte Zugriff auf den Parallelport einfach ist.
Wahrscheinlich werde ich zuerst alles schnell in ein Perl zusammen schustern um es dann ordentlich C umzusetzen, wenn ich mir über die Interne Strukturen klar geworden bin. Aber wie ich schon sagte ich bräuchte dafür zwei Tage Ruhe. Ich habe aber keine Ahnung ob mir meine Familie die in der nächsten Zeit gönnt. ;)
Weiter gedacht sollte es sogar möglich sein alle Laufwerke im PC vom Atari mit benutzen zu lassen. Aber das werde ich wohl nicht so einfach hin bekommen, da mir hier einiges an Erfahrung fehlt. Auch Implementierungen auf anderen Betriebssystemen könnte ich nur Hilfestellung geben.
Auf dem Atari habe ich bisher nur in GFA-Basic umfangreicheres geschrieben. Ein ganz klein wenig C und ein paar Brocken Assembler habe ich auch schon benutzt.
-
Um etwas ausführlicher zu werden.
Das Busprotokoll vom ACSI besteht aus 6 Byte, darin wird die Geräteadresse, der Befehl und zusätzliche Informationen zum Befehl untergebracht.
Die Basisbefehle sind:
- Test Drive Ready (Befehl &H00)
- Restore to Zero (Befehl &H01)
- Request sense (Befehl &H03)
- Read Sector (Begehl &H8)
Ohne die wird ein Gerät am ACSI-Bus nicht erkannt.
weiterhin wird dann noch
- Seek (&H0B)
- Format (&H04)
- Write (&H0A)
etc. gebraucht
Das Atari Profibuch gibt ausführlich Informationen darüber.
Auf dem PC wird ein direkter Registerzugriff auf den Parallelport gebraucht, da kein bekanntes Parallelport Protokoll benutzt wird. Ich habe versucht mich recht nahe ans ECP zu halten, aber es gibt einige Abweichungen, auch was einen Buszyklus betrifft.
Wie ich schon schrieb werde ich es auf Linux umsetzen. üder "/dev/port" hat man direkten Zugriff auf alle Hardwareregister im PC.
Grundsätzlich lauscht das Programm am Parallelport ob PaperError (verbunden mit /CS) zusammen mit Select (A1) low wird, dann wird ein Byte über D1-D8 gelesen, wenn die Gerätedresse bekannt ist, dann wird /SelectPrinter(/IRQ) auf low gezogen und die restlichen 5 Bytes geholt.
Alles weitere ist auch nicht komplizierter.
Schwierig wird es wenn man mehr will als eine einfache (Megafile) Festplatte mit bekannter (fester) Größe zu simulieren. Denn da muss man sich Zwangsläufig damit auseinander setzen, wie am Atari der Festplattentreiber Festplattengrößen bestimmt und wie ACSI-SCSI Interfaces intern funktionieren. Das dürfte etwas mehr Arbeit sein und ist nicht an einem Wochenende Gemacht. :-)
-
Ich hatte etwas Zeit und habe einen Adapter entworfen mit dem es möglich sein sollte ACSI-Geräte am Parallelport zu betreiben. (Die Idee kam mir gestern Abend noch) Aber auch hier fehlt noch sämtliche Software. Möglicherweise versucht sich jemand an eine Integration in einen Emulator (Hatari Aranym ?)
Das Fehlende "/Reset" wird erzeugt wenn /Strobe und /Autofeed gleichzeitig high sind. Einzeln steuern sie A1 und /ACK an. Das funktioniert, da A1 und /ACK Niemals gleichzeitig aktiv sein dürfen. (auch wenn es von der Atari-Hardware her möglich wäre.)
Wenn ein PC eingeschaltet wird sind /Strobe und /Autofeed per Default High, das bewirkt das /Reset solange aktiv ist bis ein Programm oder Treiber den Parallelport passend nutzt. Das sollte (denke ich) verhindern, dass irgendwelche Systemtreiber oder Programme aus versehen auf einer der Platten herum schreiben.
-
Finde es immer wieder toll was hier für Ideen umgesetzt werden. Hoffe das alles klappt wie du es dir vorstellst. Schön wäre eine Anbindung an einen der freien Emulatoren wie Hatari oder Steem. Daten hin und her kopieren zu können ist schon eine coole Sache.
-
Ein kleiner Zwischenbericht.
Ich habe das Kabel zusammen gelötet. Und eine kleines Testprogramm geschrieben, um auf den Parallelport zugreifen zu können.
Aber wie es Aussieht funken mir die Pullup Widerstände (4.7K??) des Parallelports dazwischen. Vor allem die Datenleitungen und A1 machen da Probleme, da sie auch am Disketten Controller hängen. Eine Festplatte dazwischen sollte das Problem schon lösen. Im STE und TT (wahrscheinlich auch im Falcon) sind auf den Leitungen Treiber-ICs vorhanden, die das Problem auch beheben würden.
Nur in den STs hängt der DMA-IC und FDC und ACSI an den selben Leitungen.
Ich werde mal schauen, ob ich mit ein Paar Widerständen in den Leitungen etwas ändern kann. Aber eventuell werden dann die Signale zu schwach. Mal schauen.
Notfalls muss ich Leitungstreiber einsetzten und die über USB mit Strom versorgen.
Nebenbei Macht sich so eine Störung dadurch bemerkbar, dass Disketten Zugriffe Müll liefern. Kryptische Zeichenfolgen als Datei-/Verzeichnisnamen, nicht existente Dateien/Verzeichnisse, lange Zugriffszeiten.
-
Ich habe es bisher über einen Loop in C versucht die Daten auf dem Bus ab zu greifen, aber wie es scheint reagiert der PC nicht schnell genug. Das Programm bekommt nur sporadisch mit wenn /CS low wird. Ich denke der Impuls von ATARI ist ein klein wenig zu kurz.
Ich werde Mal /CS an /ACK von Parallelport hängen und schauen ob ich über einen Interrupt das /CS Zuverlässig registriert bekomme. Und der Zugriff schnell genug ist, um noch die Daten mit zu bekommen.
Wenn alle Stricke reißen werde ich eine kleine Pufferschaltung zusammen bauen müssen um die Signale so lang zu Speichern bis der PC sie lesen kann.
Wäre der PC- der Host wäre das alles kein solches Problem...
-
*respekt an*
Toll, was Du da ausknobelst! Kann leider nix dazubeitragen, freue mich aber wenn Du das hinbekommst ;)
Cya...bph
-
Hallo,
eine sehr interessante Idee. Ich kenne mich damit nicht aus, aber ich hätte es aufgrund der timings die so ein BUS-System nutzt wohl für unmöglich gehalten.
Wie es mit der Pufferung der Signale wie "DATA" oder "ACK" ist, weiss ich auch nicht... aber ich hätte gedacht sowas kann man nicht puffern, weil der Atari zumindest eine reaktion in manchen Situationen erwartet (und das innerhalb einer bestimmten Zeit).
Auf jeden Fall ein Interessante Idee und wenn die Verbindung erstmal steht ( gibt es eigentlich für sowas ein Testprogramm?? Evt. die "Festplatten erkennung" in den diversen Festplatten-Support-Tools? ) Wie kontrollierst Du das alles richtig funktioniert? Ich glaube ich würde auch auf der Atari Seite ein kleines TestProgramm nutzen wollen, mit eingabefeld für adresse und nem Button "lesen". Wenn dann auf der PC Seite eben diese Adresse zum lesen angefragt wird, wäre ich sicher das die Kommunikation soweit schon mal klappt...
Viel Erfolg! :)
-
Ja das Timing scheint tatsächlich ein Problem zu sein. Wenn das Handling über Interrupt nicht funktioniert, dann werde ich eine kleine Schaltung bauen, welche ein Byte zwischenspeichert, bis der PC dieses abholt. Das sollte so ähnlich funktionieren wie für meine Multi-IO-Karte. Ein Buszugriff ist recht simpel und leicht in Hardware zu packen. Ein paar Bustreiber und Buffer reichen da aus. (ls244 ls245 ls373)
Die Antworttimings sind sehr großzügig bemessen. So wartet das TOS bis zu einer Sekunde auf eine Antwort (wenn es um die Adressierung eines Gerätes geht.) Weiterhin werden die Wartezyklen über die ACSI-Treiber realisiert. Daran kann man immer noch herum patchen. :)
Auf dem PC nutze ich die libieee1284 zum auf den Parallelport zu zugreifen. Das sollte auch einigermaßen portabel sein. Da habe ich was in C zusammengeschustert. Auf dem Atari läuft ein kleines Programm in GFA-Basic, das kontinuierlich Bitmuster auf den ACSI-Bus schreibt. Da die Folge feststeht kann ich am PC sehen ob die Daten vollständig übertragen wurden. Später werde ich es erweitern, dass es auch korrekt adressiert sowie Lese- und /DMA-Zyklen macht. Das mache ich aber immer erst dann wenn ich es brauche.
Mal sehen wie das ganze voran schreitet. :-)
-
Welch ein Ärger.
Der Interrupt am Parallelen Port reagiert nur auf eine steigende Flanke. Ich muss das /CS Signal aber an der fallenden Flanke haben, damit die Daten noch gültig sind während sie gelesen werden. Wenn mir keine Lösung einfällt ist die einfache Variante eines Adapterkabels endgültig vom Tisch.
Hmm wobei...
Ein NPN-Transitor als Inverter ginge sicherlich, aber der verschleift das Signal und könnte die Leitungstreiber im Parallelport grillen...
-
Moin,
vielleicht klappt ja ein Zugriff auf eine Atari Festplatte durch den PC. Würde wohl schon ein Lesezugriff reichen um alte Daten zu retten/in den PC zu portieren.
Leider renoviere ich immer noch und ziehe gleichzeitig um. Nebenbei noch zur Arbeit, deshalb keine Zeit in dieser Richtung zu helfen. Aber falls Du irgendwelche Bauelemente oder so brauchst, vielleicht hab ich ja das Passende rumliegen.
Gruß
skul
-
vielleicht klappt ja ein Zugriff auf eine Atari Festplatte durch den PC. Würde wohl schon ein Lesezugriff reichen um alte Daten zu retten/in den PC zu portieren.
Zu so einem "Master-Adapter" hatte ich auch schon eine Schaltung Entworfen. Die ergänzt auch ein fehlendes Signal. Das liegt aber Erstmal so lange auf Eis bis ich den "Client-Adapter" fertig habe. An dem Habe ich zur Zeit größeres Interesse.
Beim "Master-Adapter" wäre ich an eine Integration in Hatari (oder einem anderen Emulator) interessiert. Einen Kompletten ACSI-Treiber mit Dateisystemunterstützung zu schreiben wäre nicht so meine Stärke.
-
Ich war nicht Tatenlos.
Von einem Bekannten habe ich mir ein Oszilloskop und ihn selber ausgeliehen, um mir die Signale am ACSI-Port an zu schauen. Und ich kann sagen: Gott sind die Scheiße! Die haben Nicht mal annähernd eine Rechteckform. Die Signale von D0 bis D7 haben eine Parabolisch ansteigende Flanke und dann nach einer 5V-Spitze fällt das Signal auf 0V ab. Das /CS-Signal ist so kurz, das es das 20Mhz Oszilloskop gar nicht auflöst.
Das habe ich an einem verbastelten 1040STF gemessen, den ich hier zum Testen habe. Ich habe einen anderen aus meinem Fundus geholt, aber der zeigt das selbe.
Ich habe keine Ahnung warum ich ich mit meinem ACSI-MultiIO keine Probleme dahingehend hatte. Vermutlich sind Die 74LS-ICS schnell und tolerant genug dafür.
Ich werde mal schauen, ob ich mit Schmitt Triggern etwas reißen kann.
Nach ein paar Tests am Parallelport scheint es so zu sein, dass Ein Signal erst erkannt wird, wenn dieses Mindestens 200ns sauber auf einem Pegel war. Ich würde nun gerne das Trigger-Signal (/CS) Strecken, so das ich ein aktiven Pegel von 300ns bekomme, damit ich auf der sicheren Seite bin. Weiß jemand wie man ein TTL-Signal "strecken" kann?
-
Interessantes Projekt, was ist denn daraus geworden?
Wäre es nicht einfacher, den ST per SCSI-Adapter (von ICD oder so) an den SCSI-Port des PC zu hängen, und dann auf dem PC eine SCSI-Platte als Image zu simulieren?
(Toll wäre dannn natürlich, wenn man aus dem PC heraus auf dieses Image (wenn der ST aus ist!) zugreifen könnte, um Daten hin und her zu schaufeln.)
-
Ich habe gerade etwas wenig Zeit dafür, aber vergessen ist es nicht.
Es gibt einige Timing-Probleme. So einfach wie ich es mir vorgestellt habe geht es leider nicht. Der PC reagiert auf die Interrupts ein tacken langsam und bei Loops/Timern funken mit andere Prozesse dazwischen (ist halt kein Echtzeitsystem). Die Lösung, die mir dazu einfällt, ist alle Signale zu puffern. Die Schaltung habe ich entworfen, ich komme nur nicht dazu sie aufzubauen und zu testen. Mal sehen ob ich im Sommer wieder etwas Zeit dafür finde.
-
Schnapp dir einfach den Schaltplan einer Atari Megafile 20/30 und pick dir die Pufferung da heraus. Das sind nur ein paar wenige TTL-ICs.