Altes Computing Interface Probleme mit Eingängen

[markpot4]

Hi ich wollte versuchen das alte Computing Experimental mit dem damaligen Universal Interface zum laufen zu bekommen.

Die Ausgänge funktionieren alle ohne Probleme. Jedoch hab ich Probleme das bei den Eingängen.
Beim Computing Experimental Programm das über Basic läuft hab ich da im Diagnoseprogramm überall eine 1 stehen egal ob ich einen Eingang drücke oder anschließe es rührt sich gar nichts.

Ich benutze einen IBM WIn95 Laptop mit Pentium MMX Prozessor (200mhz). Der Laptop ist aus dem Jahr 1996. Ich hab schon öfters gehört das die Pentium Prozessoren für das Computing Experimental schon zu schnell sein sollen und es Probleme beim Timing oder mit Prellen gibt. Habe deswegen Slomo probiert um die Taktung herunterzusetzen, jedoch hat das auch nichts gebracht.

Ich hab das ganze dann mit TurboPascal vom Profi Computing probiert und da reagieren die Eingängen zwar aber es werden immer 2 Eingänge auf einmal gesteuert. Zb wenn ich E1 drücke gehen E1 + E2 auf 1 anstatt nur E1.

Das Interface und die Steckleiste selbst haben keine Probleme denn mit einer noch neueren Software LLwin funktioniert da ganze.
Jedoch möchte ich das ganze auch gern irgendwie mit Basic und Turbopascal zum laufen bekommen

Gibt es irgendeinen weg das ganze zum laufen zu bekommen ohne einen noch älteren pc zu kaufen? z.b. einen bestimmten Wiederstand oder Kondensator beim Eingang zwischenzuschalten?

[fishfriend]

Hallo...
Ja, das alte TurboPascal hat ein "Zeitproblem" was es nicht lauffähig auf schnellen neuen Rechnern macht.
Die internen Pausen sind scheinbar zu kurz, so wie ich es in erinnerung habe.

Hast du noch andere Möglichkeiten was zu messen? Also am besten einen billigen Logik-Sale-Klon oder noch besser das original .
Ich hätte auch die Stecker in verdacht.
Welches Interface hast du genau. Das ganz alte mit Transitoren, das mit festem Stecker, CVK... ? Am besten mal ein Bild machen.
Sind die IC in einer Steckfassung? Ansonsten einfach mal rausnehmen und wieder reinstecken.

Am Pin 3 vom 4014 IC sollte immer eine 0 sein, wenn nichts angeschlossen ist.
Wenn der 4014er in einer Fassung steckt, kann man das auch mal abziehen und das Interface ohne laufen lassen. (Da geht nichts kaputt)
Das Programm muss dann bei den EIngängen eine 0 anzeigen. So könnte man zumindest weite Fehler ausschließen.
Mit freundlichen Grüßen
Holger

[markpot4]

Ich hab das Universalinterface von Profi Computing Modell 30520. Also das wo man jeden Stecker drauf tun kann egal ob IBM, c64 etc.
Einen IC gibts in einer Steckfassung (4014) die restlichen ICs sind angelötet.
Habe den IC 4014 herausgenommen und es sind immer noch alle auf Eingänge auf 1, selbst dann wenn ich keine Steckbuchse mit den Eingängen angeschlossen hab. Das interessante ist wenn ich die Steckbuchse mit den Eingängen anschließe und dann irgendeinen Beliebigen Eingang von der Stechbuchse mit der Erdung bzw Gnd vom Interface verbinde gehen plötzlich alle Eingänge auf 0. Allerdings bleiben sie dann für immer auf 0 und gehen nicht auf 1 sobald ich einen Schalter drücke.

Was ich mir sonst noch vorstellen kann, ich verwende ja das etwas neuere Interface. Computing experimental mit Basic war ja noch mit den noch etwas älteren Interfaces mit den Transistoren vorgesehen, wovon ich allerdings keines besitze. Vlt war das noch ältere Interface anders verschaltet sodass das nur das alte Interface mit Basic funktionierte oder sollte das keinen Unterschied machen?

[FiTeN3rd]

Hallo, frohe Ostern!

Zur Diagnose hätte ich noch die Frage, ob bei Deinen Versuchen die rote LED leuchtet?
Das war bei meinen Versuchen das große Problem. Die neueren (so ab 1988, 1989 ) parallelen Schnittstellen haben nur noch um die 3 Volt (statt früher 5 Volt) Pegel. Eventuell hast Du "einfach" ein Problem mit den Pegeln vom PC.
Zur Auswertung hatte ich damals (vor 4 Monaten) einen Logik-Analysator verwendet und die Signale an den 5 + 1 Leitungen zusammen aufgezeichnet. Dann habe ich den Tip mit dem Pull-Down der Puls-Leitung gefunden (hierzu siehe bitte meinen Artikel in der letzten ft:pedia).
Allerdings sollte der Trick mit dem Einlesen der Eingänge nix zu tun haben, das hatte bei mir trotzdem gut funktioniert. Die Sache mit den zwei "gleichzeitigen" Eingängen bei nur einem betätigten hatte ich zuerst auch, bis ich festgestellt habe dass der "erste" Kontakt (E8) einen Wackelkontakt hatte. Nach erneuter Überprüfung aller Kontakte am "Brett" hat sich der Effekt nicht (nie) mehr gezeigt.

Liebe Grüße aus Braunschweig, viel Erfolg weiterhin!
Matthias (FiTeN3rd)

[fishfriend]

Hallo...
Ich denke, es hat mit dem TurboPascal selbst zu tun. Der ließt den Eingang so schnell ein, das es nicht funktionieren kann.

Wenn man es mit TurboPascal machen will, könnte ich mir vorstellen, dass man die Robo Connect Box nehmen "könnte" und es dann versuchen.
Das ist wohl sehr viel Aufwand und man hat die richtige Timings nicht, da es über USB geht und es nicht Echtzeitfähig ist.

Mit freundlichen Grüßen
Holger

[markpot4]

Die Rote LED funktioniert und lässt sich mit Call IIN mit Basic ansprechen wie es auch in der Anleitung steht. Wenn ich das Diagnoseprogramm von Computing Experimental starte wo ich die Schalter und Motoren testen kann leuchtet dann die LED durchgängig (ich denke auch das soll so sein).

Ich hab das Problem mal die GPT gefragt und der meinte man sollte bei jeden Eingang einen 10kOhm Wiederstand als Pull down setzen und mit der Masse verbinden, das sollte das Problem lösen. Ich weiß aber nicht wie sehr ich der KI bei sowas vertrauen soll, bin da lieber vorsichtig bevor ich was kaputt mache und herumexperimentiere.

Ich hab den Parallelport geprüft und der hat 5V wie für das Interface vorgesehen, das sollte als nicht das Problem sein.

Etwas das mir außerdem noch bei Basic aufgefallen ist das die Eingänge ab und zu "Flimmern/Prellen" also meistens auf 1 bleiben ab und zu zwischen 0 und 1 hin und her springen. Das selbe "Prellen" hab ich auch bei Turbopascal bei dem Eingang der mitgesteuert wird. ZB drücke ich E3 wird immer der darunterliegende mitgesteuert in dem fall E2. E3 bleibt immer auf 1 während E2 zwischen 0 und 1 hin und herspringt.

Einen Wackelkontakt oder falsche Verkablung schließe ich aber aus weil alles mit der Software Llwin korrekt funktioniert. Es scheint also eher das die Software von Basic und Turbopascal die Hardware nicht korrekt implementiert.

[fishfriend]

Hallo...
Denke ich auch. Früher hat man als Pause gerne NOPs (oder aufwendige Operationen) genommen, um ein gewisses Timing zu erzeugen. Man konnte ja die gebrauchten Tackte die eine CPU brauchte einfach abzählen. Bei nicht Echtzeifähigen Betriebssystemen, und dazu zählt Windows, ging es zu anfang gerade noch so, weil die Rechner noch realtiv langsam waren. Ich kann mich irren, aber ich meine da tauchte dann das Problem mit TurboPascal auf.
Ist halt schon lange her...

Heute geht man u.a. meist über Events beim Betriebssystem, wobei man aber meist auf der ausgelagerten intelligenten Hardware Zeitkritische Sachen macht.
Für "heute" könnte man einen Arduino nehmen, der vom PC aus gesteuert wird, der dann das fischertechnik Interface steuert. Oder so.
Man hat dann eine virtuelle COM über den USB Anschluss, wo es fast egal ist wann die Übertragung geht und den Arduino, der die Impule genau zählen kann - soweit man soviele schnelle (Hardware-) Zähler hat (wie z.B. Mega...).
Denn auch mit einem UNO geht es so nicht, da der nur einen hat.

Mit der RoboConecktBox kann man zwar das Interface zum laufen bekommen, aber wirkliche Zeitkritische Sachen kann man auch nicht hinbekommen.
Wobei man dazu sagen muss, das es wohl bei 99% der ft-Modelle geht. Aber z.B. die Impulse beim Trainingsroboter zählen, wird schon sgaen wir mal sportlich oder es geht nicht.

Es ist ja von Damals schon eine ganze Zeit vergangen. Ich könnte mir vorstellen, das schon andere eine Lösung für Turbopascal gefunden haben, wie man das umgehen oder fixen kann. Ich selber kenne diese Lösungen aber nicht.

Soweit ich mich erinnere gab es zum Basic einen eigenen Treiber. Der war garnich so lang und man "könnte" den abändern. Ob man dann den zum laufen bekommt ist noch eine andere Frage, da ja auch noch andere Diesnte wie z.B. die Uhrzeit stellen, Tastatur, Maus abfragen usw. damit in Konflikt kommen können und das Betriebssystem den dann ruasschmeißt. Früher war das nicht so ganz das Problem.

Ist schon lange lange her, aber das Programm meine ich, überträgt die Daten ja garnicht parallel, obwohl ja die parallel Schnittstelle genutzt wird. Die Daten werden seriell übertragen. Man könnte sich auch mal überlegen ob man nicht direkt von TurboPascal, über USB an einen USB/TTL Übertrager (und vermutlich dann etwas verlagsamt) an das fischertechnik Interface senden kann. Ich gebe aber zu, das meine TurboPascal Zeiten ewig her sind.
Mit freundlichen Grüßen
Holger

[FiTeN3rd]

Hallo noch einmal,

in den letzten Stunden habe ich mal ein wenig untersucht, woran Deine Probleme liegen könnten.
Mit einem Windows XP PC mit paralleler Schnittstelle habe ich das Interface in einer DOS-Umgebung (nicht in einer Windows XP-Dos Box!!!) ohne Probleme zum Laufen gebracht.
Dazu habe ich GWBasic verwendet, in diesem Programm kann man sogar mit IN und OUT direkt auf die Ports ( #03BC LPT1 ) zugreifen.
Im Original stellt Fischertechnik ein kleines Assembler-Progrämmchen zur Verfügung, was für jedes Programm "dazugeladen" werden muss.
Den direkten Zugriff habe ich auch erfolgreich ausprobiert - aber in einer MSDOS-Umgebung.

Sobald man in die Windows-Welt springt, verhält sich die Umgebung komplett unterschiedlich, weil das oder die Betriebssystem(e) WIN 3.1 aufwärts nicht mehr so locker mit den Ports umgeht. Soweit ich mich erinnere und recherchiert habe, konnte Turbo Pascal 5.0 gar nicht direkt , also etwa über einen Befehl, auf I/O-Ports zugreifen. Nach 5.0 hat Turbo Pascal dann auch erst die Windows-Welt erobert. Seinerzeit habe ich viel mit Turbo-Pascal unter CP/M oder auf dem PC unter MSDOS programmiert, so etwas wie eine seriell über den Parallelport umgesetzte Kommunikation ist mir dabei ansonsten nie untergekommen. Das betreffende Interface hat sehr gut in "seine Zeit" (von 1986 bis etwa 1992) gepasst, später aber weniger.
Und mal so als wohlgemeinte Warnung: Die DOS-Box unter Windows ist in einiger Hinsicht eben nicht das Gleiche wie ein "Stand Alone" MSDOS.

Warum funktioniert das dann mit LLWIN? ich denke mal, dass Fischertechnik die notwendigen Port-Zugriffe ordentlich gekapselt hat (mindestens Interrupt ausschalten, zugreifen, Interrupt wieder an) - genau wie das das zuvor erwähnte Assembler-Progrämmchen getan hat.
Meine Vermutung: Deine Versuche scheitern, weil den Port-Zugriffen durch Basic oder Pascal irgendetwas "dazwischen" bzw. das Timing durcheinander kommt. Mit welchen Befehlen greifst Du denn unter Basic oder Pascal auf die Ports zu? Gab es von Fischertechnik irgendein Teilchen Software, das in Basic (per MERGE) oder Pascal (als OBJ) dazu geladen werden muss?
Falls nämlich nicht, dann steht Dir die Arbeit bevor, diese PORT-Zugriffe selbst in der Sprache Deiner Wahl zu implementieren - Turbo Pascal konnte Inline Assembler. Der damals übliche Weg war der über API-Zugriffe.

Ansonsten gab es einige 32-bittige Ansätze, schau mal in der ft:pedia in den Artikeln von Helmut Jawtusch (3/2017 ab Seite 53, 4/2017 ab Seite 34).

Denn mal viel Erfolg!

Liebe Grüße aus Braunschweig,
Matthias