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

[markpot4]

Ich verwende Win95 ohne VM und hab sogar probiert Win95 im reinen DOS-Modus ohne Grafische Umgebung zu starten. Beides hat leider die selbe Auswirkung.

Ich benutz da immer die Call begriffe zb: CALL I1R um einen Motor in eine bestimmte Richtung zu steuern. Und CALL IDE um Eingänge Einzulesen. Und mit print E1, E2 etc kann ich dann theoretisch schauen welchen Wert der Eingang hat. Das Problem ist nur sobald ich aber den Befehl CALL IDE eingebe was die Eingänge einlesen sollte stürzt bei mir die komplette DOS Commandline ab (also anscheinend irgendein Überlauf bei den Eingängen der zum kompletten Absturz führt). Die Eingänge selbst kann ich also nur in dem Basic-Diagnoseprogramm auslesen was auf der fischertechnik diskette dabei ist und dort sind Eben alle auf 1 und auch EX und EY 1023 also ich schätze mal einfach am höchstmöglichen wert. Selbst wenn ich einen analogen Eingang was anschließe zb Tempsensor daran tut sich rein gar nichts bei den zahlen und er bleibt immer auf 1023.

Hast du bei deinem Test mit WinXP auch das Universalinterface verwendet oder das damals zugehörige alte IBM Transistorinterface? Weil vlt passt auch einfach der Basic Treiber nicht zum Universal-Interface weil er ja ursprünglich für das alte IBM interface gedacht war das doch eine andere Verschaltung hat als das Universal-IF das ich besitze. Das würde das Problem erklären wieso Basic bei mir nicht funktioniert, also möglicherweise geht es wirklich nur mit dem alten IBM Transistoren Interface.

Für Turbopascal hab ich allerdings das genau richtige Interface also das erklärt dann leider nicht wieso es hier nicht funktioniert. Auch das alte Dos Lucky Logic (erstes Grafisches Programmierprogramm von FT) was passend zu meinem Interface ist hat auch 1:1 selbe Problem wie Turbopascal mit den mitgehenden Eingängen.

[fishfriend]

Hallo...
So gesehen hat das mit der Art vom Interface selbst nichts zu tun. Im Grunde sind die gleich ausgebaut und haben "nur" andere Motortreiber.
Die BD Transistoren gehen nun mal schneller durch als das Treiber IC. (Z.B. bei Kurzschluss, Rückspannung...)
Bei den Universal Interface sind manche IC Anschlüsse nach außen auf den (wechsel) Stecker geführt. Das hatte den Grund, das bei manchen Computern die internen A/D Wandler z.B. vom Joystick genutzt wurden, um die analogen Werte zu erzeugen. Je nachdem welchen Stecker man benutzte wurde ausgewählt, ob der NE555/NE556 genutzt wurde oder nicht. Bei den interfaces mit den "festen" Steckern sind die Ausgänge fest mit den jew I/O des jew. Computers verbunden. Im Grunde kann man auch ein C64 Interface an einen PC anschließen. Man muss nur die richtigen Aus- und Eingänge verbinden. Schaltungstechnisch sind die im Grunde gleich.

Für den parallen Port/IBM wurden die Zeiten gemessen, die der NE555 erzeugt. Jenachdem wie groß der Widerstand am analogen Eingang war verlängerte oder verkürzte sich der Wert dann.

Die digitalen Eingänge werden durch einen Parallel-Seriell Wandler eingelesen. Dazu wird ein Tackt vom genommen und die einzelnen Eingänge hintereinander auf den Anschluss gegeben.
Mit den Ausgängen ist es nun genauso, nur andersherum. Hier werden die Daten seriell eingelesen und parallel ausgegeben.

Das Problem ist nun "das" Timing.
1. Wie schnell werden die Daten übertragen? Kommt das Interface da mit? Oder macht der PC gerade andere Sachen?
2. Auf welcher Ebene vom Betriebsystem hab ich Zugriff auf die Ports?
3. Wie sind die Pausen zwischen den Signalen? Kann die I/O vom PC den Ausgang richtig setzen oder lesen.

Ich sags mal so, um sich das besser vorstellen zu können. Wenn Windows z.B. mit der Auslagerungsdatei beschäftigt ist, wird die Zeiteinteilung für I/O Zugriffe etwas minimiert. Wenn man nun feste Zeiten programmiert, um einen Ausgang zu schalten, kann man nicht genau sagen wann die anfangen oder enden. Es kann noch passen oder halt nicht. Und hier scheinbar passt es nicht.

Ich hab mal vor langer Zeit die verschiedenen Interfaces untersucht und einen "Schaltplan" der jeweiligen Interfaces gemacht, wo die unterschiedlichen Ausgänge zu sehen sind.
https://ftcommunity.de/knowhow/computin ... erface.zip
Da sind BMP bzw die Eagle Schaltungen drinn.

Mit freundlichen Grüßen
Holger

[markpot4]

Ich konnte mittlerweile 1 von 2 Problemen lösen.

Das bei Basic alle Eingänge auf 1 waren, war tatsächlich ein Problem der zu Schnellen CPU, hab das ganze dann mit SlowDown runtergetaktet und
jetzt reagiert Basic auf die Eingänge. Allerdings hab ich dort jetzt das selbe Problem wie bei Turbopascal mit den mitziehenden Eingängen. Das Problem ist mit SlowDown anscheind leider nicht lösbar. Wenn ich dort den zweiten Regler für Reaction ändere dauert es einfach nur länger bis die 0 auf 1 springt aber das Signal geht trotzdem auf den Benachbarten Eingang mit. Vlt hilft ein Wiederstand das Signal irgendwie stabiler zu halten?

Ich habe auch ein Professionellers Programm: Mo'Slo 4BIZ gefunden das allerdings 25€ kostet: http://hpaa.com/moslo/4biz.asp
Dort kann man anscheind zusätzlich noch Delay, Duration und andere Einstellungen vornehmen. Glaubst du lohnt sich das zu kaufen und das Problem zu lösen oder macht das das komplett selbe wie SlowDown? Bei meinem Programm kann man nur Speed und Reaction verstellen.

Was ich noch probieren könnte wäre das ganze auf reinem DOS zum laufen zu bringen vlt läuft es da ja eher da sich weniger Hintergrundprogramme gegenseitig beeinflussen.

mfg

[fishfriend]

Hallo...
Gegenfrage, was bzw welche Modelle willst du damit steuern?

Grundsätzliches zu den Widerständen. Ja, Pull Up oder Pull Down können helfen die Zeit zum "ausräumen" der Ladungsträger zu verkürzen - muss es aber nicht
Man "kann" sich noch andere Probleme damit einhandeln. Das bezieht sich aber eher auf relativ hohe Frequenzen (Umschaltungen des I/Os). So ein Beispiel sind Widerstände bei I2C Schnittstellen statt der 3,3V zu 5V "Umsetzer".

Die "Königsklasse" sind halt Analoge EIngänge und die Lichtscharken beim Roboter.
Die "normalen" Modelle werden wohl so funktionieren, denke ich.

Ich persönlich, würde mir das Programm nicht kaufen. Zumal dir dabei auch kaum einer aus dem Forum helfen könnte, weil es nicht so verbreitet ist.
Das was schon einige gemacht haben (ich auch) ist halt die Modelle mit mordernen Interfaces anzusteuern. Wenn man wirklich alles alt haben will, muss man sich auch einen alten Rechner dazu holen, Es ist aber wohl eine aussterbende Art die sich das noch antut.
Die neueren Interfaces kosten gebraucht auch nicht mehr so viel oder man nimmt einen Aurdunio und co. Ob es nun unbedinngt Pascal sein muss ist auch noch eine Frage. Ich gebe zu ich hab meine Bücher dazu wegeworfen

Was man mal versuchen könnte ist eine andere Lösung mit der RoboConnekt Box und halt RoboPro. Ist jetzt auch nicht mehr das neuste.

Ich glaube meine DOS Zeit ist vorbei. Auch meine DIsketten dürften nicht mehr lesbar sein geschweige denn das man ein passendes Laufwerk hat oder auf dem Dachboden noch findet.
Mit freundlichen Grüßen
Holger