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

[markpot4]

Ich möchte damit die Computing experimental und Profi Computing Modelle zum laufen bekommen. Klar könnte ich ca 90% der Modelle auch mit LLwin oder Robo Pro umsetzen aber mich reizt es einfach auch mal bisschen mit Text zu programmieren und alte Programmiersprachen kennenzulernen. Außerdem gibt es einige Turbopascal und Basic Modell die auf der Commandline Text ausgeben oder per Commandline eine Texteingabe abfragen und ich denke das ist mit den Grafikbasieren Programmen wie LLwin, RoboPro etc. nicht möglich. Deswegen fallen dann dann 10% der Modelle weg die man zumindest nicht ganz wie vorgesehen zum laufen bringen kann oder halt irgendwie anders ohne Texteingabe/Ausgabe lösen muss. Soweit ich weiß kann man mit RoboPro und Llwin nur analog-Sensorwerte textmäßig auf so einem Feld ausgeben.

Ich bin jetzt auf noch auf etwas gestoßen das möglicherweise die Lösung meines Problems könnte und eig extrem simpel ist. Kann das allerdings erst frühestens am Wochenende testen sobald mein Usb-diskettenlaufwerk das ich bestellt habe angekommen ist, da ich dafür ein eigenes Utility tool brauche um den Parallelport-Modus umzustellen. Mein win95 Laptop hat leider noch keinen usb port zur Datenübertragung es geht da leider nur über Diskette oder CF Kartenübertragung also passend zur zeit sehr oldscool xD


Zu meiner Idee: Ich hab herrausgefunden das der Parallelport verschiedene Arten von Übertragungsgeschwindigkeiten hat: SPP (standart paralell port), EPP (enhanced parallel port) und ECP (Extended Capabilities Port). EPP funktioniert bidirektional, ECP über direkt Memory access und SPP über direkte Bitansteuerung. Also möglicherweise liegt einfach da der Hund begraben das der Parallelport auf den falschen Übertragungsmodus eingestellt ist. SPP ist der langsamste und wird wahrscheinlich der stabilste für die Interfaces sein. Mal schauen ob das irgendwie das Problem löst.


Ich muss sagen das Disketten bei mir tatsächlich relativ lange halten. Meine fischertechnik Disketten sind alle noch problemlos lesbar. Und es gibt dafür ja auch USB-Diskettenlaufwerke um die auf neueren pcs einzulesen ohne das man extra ein Laufwerk in den PC einbauen muss. Teilweise findet man sogar die alten ft-Programme noch auf archive.org falls mal eine Diskette defekt wird. Also ich denke das sind hier noch eher die kleinsten Probleme xD Die großen Challenges sind eben eher mit alten Interfaces und den dazugehörigen alten Programmen. Also alles was halt vor der IntelligentInterface-Zeit ist.
mfg Mark

[fishfriend]

Hallo...
Hast du die Möglichkeit auch zu messen?
Ok, es gab auch die Einstellungen und ich denke man kriegt auch über das Mainboard jede Menge Infos.
So viele EInstellungen sind es ja auch nicht.

Ich gebe zu im Zusammenhang mit den fischertechnik Interfaces hab ich nie diese Einstellungen geändert.
Ich hab auch noch Disktetten, benutze sie aber schon lange nicht mehr.

Dann sind wir mal gespannt was noch so kommt.
Mit freundlichen Grüßen
Holger

[markpot4]

So kleines update. Der IBM Laptop hat anscheinend nur eine fixe Parallelport-Einstellung und kann nicht umgestellt werden.

Mittlerweile hab ich jetzt aber Luckylogic und Turbopascal zum laufen gebracht. Ich hab auf Archive.org eine neuere Version von Luckylog gefunden. Ich selbst verwende 3.03 und die version dort ist die 3.07 https://archive.org/details/lucky-logic-3.07. Damit funktioniert sowohl Turbopascal und Luckyllogic Problemlos. Anscheinend wurde da das Timing angepasst das es auf schnelleren PCs läuft.

Das einzige das leider noch nicht klappt ist Basic und das lustigerweise obwohl extra eine Basic version beim 3.07 Luckylogic inkludiert ist. Hier wurde irgendwie das timing nicht angepasst. An der fischertechnik.dat Datei also der config datei die am anfang geschrieben wird liegt es jedenfalls mal nicht die hab ich sowohl bei basic und auch veruscht beim alten 3.03 luckylogic versucht durch die neue zu ersetzen und immer noch das selbe Problem. Bleibt also herrauszufinden was genau an der luckylogic und t-pascal 3.07 geändert wurde um das ding zum laufen zu kriegen und wieso das Problem bei Basic nicht gefixt wurde. Selbst im reinen DOS ohne Hintergrundprogramme klappts nicht. Möglicherweise ist Gwbasic selbst einfach zu alt, das kam ja alles vor der Luckylogic und Turbopascal Zeit.

Zwecks messen hab ich halt ein Standart-Multimeter daheim um Spannung, Stromstärke, Wiederstand zu messen.

[fishfriend]

Hallo...
Schon mal scön das es teilweise läuft.

Luckylogic, tja das waren noch Zeiten...
Hintergrund
Also, ich damals mich sehr intensiv damit beschäftigt. Luckylogic ist kein Programm was fischertechnik entwickelt hatte. Das war eine andere Firma.
Ich hatte damals Kontakt zu denen aufgenommen. Das Programm wurde für Steuerungszwecke entwickelt, um größere Maschinen und sogar große Anlagen zu steuern. Die haben das minimiert und ft hat das dann vertrieben. Witzigerweise konnte sogar die ganz große Version bis zu einer gewissen Version (hab die Nummer vergessen) deren Software, das ft-Interface ansprechen. Das Ganze ging so z.B. in Richtung Kraftwerkssteuerung.
Im Programmtext selber steckt auch der Name der Firma.
Die werden aber vermutlich keine Infos mehr dazu haben, falls es die noch gibt...
Ich hatte in einem der vorherigen ft-Foren mal was dazu geschrieben, aber die werden wohl kaum noch zu finden sein. Internetarchive waren damals nicht so verbreitet.
Im Programm werden die ihren eigenen "Treiber" benutzen. Die große Version konnte auch andere Schnittstellen unterstützen. Die werden damals vermutlich nicht in TP prgrammiert haben.

Was du zum messen hast, reicht so nicht aus. Mit einem (billigen 10€) Logikanalysator Clon, könnte man das messen.

Wie gesagt, es kann ja sein das es einen Pach zum Timing gegeben hat. Es waren vermutlich ja auch andere Geräte, die an der Schnittstelle betrieben wurden, davon betrofen. Wirklich durchgesetzt hatte sich das aber nicht und die Programmiersprache - starb aus...

Aus der Erinnerung
Basic hatte einen eigenen ASM Treiber, der die Kommunikation regelte. Auch damit hatte ich mich damals mal beschäftigt. Vermutlich - wenn man die Ahnung davon hat - "könnte" man den anpassen. Der Aufwand würde sich sogar noch in Grenzen halten, da man "nur" die Zeiten ändern müsste. Ich fürchte aber, das zumindest meine ASM Kenntnisse eingerostet sind, um das machen zu können. Normalerweise haben die Interpreter damals die NOPs nicht wegoptiemiert, so wie heute. Man könnte versuchen, durch einfügen dieser NOPs, die Zeiten zu verlängern. Meist lagen diese Übertragungen und Zeiten, in einer eigenen Schleife, die dann jeweils angesprungen wurde, um die Wartezeiten zu erzeugen. Wenn man also nachschaut wie lange der Prozessor für die Abarbeitung dieses Befehls braucht, kann man errechnen, wie sie sich verändert.

Mit freundlichen Grüßen
Holger

[markpot4]

Ich habe herausgefunden die Basic-fischertechnik era für einen 8086 prozessor 5mhz geschrieben wurde. Es gibt allerdings sogar beim initalisieren eine Geschwindigkeitsüberprüfung wo die treiberdatei dem prozessor angepasst wird. Allerdings schätze ich das das nur bis zu einem bestimmten prozessortyp bzw mhz-wert funktioniert. Vlt das 2-3 generationen danach zb i386 prozessor mit 25mhz noch gehen denn so lange gab es das ft computing experimental set mit basic zumindest bis es 1991 von luckylogic abgelöst wurde. Aber alles darüber (mein win95 laptop hat einen intel pentium mit 200mhz) ist dann wohl einfach fürs richtige timing zu schnell. Und updates gibts da natürliche auch keine weil das bereits vor der luckylogic und turbopascal zeit war.

Ich hab außerdem herrausgefunden das die ganze config-datei wo die eingänge eingelesen werden gar nicht im fischertechnik treiber file sondern interfac.com steckt. Ich hab mal die KI Claude gefragt ob man was am code verändern kann. Und die KI hat gemeint man soll an bestimmten stellen vom code NOPs einbauen also no operation-befehle in denen nichts passiert außer das der prozessor dort taktzyklen verbraucht und es somit eine art warteschleife für den prozessor ist.

Das war die ursprüngliche version
06BC:013C MOV AL,30
06BC:013E RCL BL,1
06BC:0140 JAE 0144
06BC:0142 OR AL,04
06BC:0144 OUT DX,AL ← Clock LOW
06BC:0145 OR AL,08
06BC:0147 OUT DX,AL ← Clock HIGH
06BC:0148 LOOPW 013C


Das dann die geänderte version
06BC:013C MOV AL,30
06BC:013E RCL BL,1
06BC:0140 JAE 0144
06BC:0142 OR AL,04
06BC:0144 OUT DX,AL ← Clock LOW
06BC:0145 NOP
06BC:0146 NOP
06BC:0147 NOP
06BC:0148 OR AL,08
06BC:014A OUT DX,AL ← Clock HIGH
06BC:014B NOP
06BC:014C NOP
06BC:014D NOP
06BC:014E LOOPW 013C


Allerdings scheint die KI bei Assembler wohl auch an ihre Grenzen zu stoßen Normalerweise vertraue ich der KI sowieso nicht aber ich dachte es wäre zumindest einen versuch wert. Hab den code ausprobiert und dann ging eigentlich gar nichts also Diagnoseprogramm startet nicht einmal mehr bzw die dos-shell hängt sich dann einfach auf.

Ich bin dann auf noch eine Möglichkeit gekommen: Dosbox-X. Das programm kann nämlich geziehlt einen Prozessortyp oder eine geschwindigkeit emulieren und auch auf den paralellport zugreifen. Problem ist nur: Dosbox funktioniert auf meinem win95 laptop irgendwie nicht obwohl es eine seprate version extra für win95 und sogar für dos gibt. Es kommt beim starten aber immer eine Fehlermeldung das es inkompatibel ist und dll files fehlen. Möglicherweise kann der Laptop oder Prozessor einfach noch keine Emulation oder es fehlen tatsächlich einfach nur dll files. Ich werde die mal aufzutreiben vlt klappt es dann.

Und wenn das auch nicht klappt ist meine allerletzte lösung:
Eine Paralellport-PCI-Karte für meinen aktuellen rechner beschaffen und da dosbox -x drauf laufen lassen. Ich denke das sollte vlt am ehesten noch funktionieren weil auf meinem aktuellen win10 rechner läuft da mit dosbox eig ohne probleme.

[steffalk]

Tach auch!

Spätestens ab 486er CPUs läuft der 16-Bit-Zähler für die Performancemessung halt über, und Du musst ein 32-bit integer zählen.

Ich hoffe, das lange Posting tut niemanden weh, aber wenn's hilft, hier meine damalige Modula-2-Implementierung als Ersatz für das Assembler aus der Anleitung zum alten Parallel-Interface. Damit liefen z.B. dieser Aufzug https://ftcommunity.de/bilderpool/model ... ery-index/ und dieser nicht fertiggestellte Plotter https://ftcommunity.de/bilderpool/model ... ery-index/.

Das Definition Module enthält die Schnittstelle - das, was man aufrufen kann:

Code: Alles auswählen

DEFINITION MODULE FischerInterface;

  (* Low-Level-Hardwareschnittstelle zum fischertechnik-computing-
     Interface. *)

  PROCEDURE Init;

    (* Schaltet alle Ausg„nge inaktiv. *)

  CONST
    Motors = 4;
      (* Anzahl der ansteuerbaren Motoren. *)

  TYPE
    Motor = [1..Motors];
      (* Die Nummer eines Motors. *)

    Direction = (* Die Richtung, in der sich ein Motor dreht. *)
      (off,
         (* Der Motor (der Ausgang) ist abgeschaltet. *)
       left,
         (* Der Motor wird zum Rechtsdrehen eingeschaltet (abh„ngig von der
            Verkabelung am Modell). *)
       right);
         (* Der Motor wird zum Linksdrehen eingeschaltet (abh„ngig von der
            Verkabelung am Modell). *)

  PROCEDURE SetMotor (n: Motor;
                      Dir: Direction);

    (* Schaltet einen der Motoren.

       in:   n     Die Nummer des anzusteuernden Motors.
             Dir   Die gewnschte Drehrichtung bzw. Polung des Ausgangs.
     *)

  CONST
    Switches = 8;
      (* Anzahl der abfragbaren Taster/Schalter. *)

  TYPE
    Switch = [1..Switches];
      (* Die Nummer eines Schalters. *)

  PROCEDURE SwitchStatus (n: Switch): BOOLEAN;

    (* Fragt einen Schalter ab.

       in:   n           Die Nummer des abzufragenden Schalters.
       out:   (RETURN)   TRUE genau dann, wenn der Schalter auf Durchgang
                         geschaltet ist bzw. die entsprechende
                         Eingangsleitung des Interfaces auf +5 V liegt).
     *)

  CONST
    AnalogInputs = 2;
      (* Anzahl analoger Eingabekan„le. *)

  TYPE
    AnalogInput = [1..AnalogInputs];
      (* Die Nummer eines Analog-Eingangs. *)

  PROCEDURE AnalogStatus (n: AnalogInput): CARDINAL;

    (* Fragt einen der Analog-Eing„nge ab.

       in:    n          Die Nummer des abzufragenden Eingangs.
       out:   (RETURN)   Eine Zahl, deren H”he in einem linearen Zusammenhang
                         mit dem an dem Analogeingang n anliegenden
                         Widerstand steht. Sonst ist ber diese Zahl nichts
                         bekannt.

       Bevor diese Funktion fr eine Steuerung verwendet werden kann, muá der
       m”gliche Wertebereich durch geeignete Maánahmen des Anwenderprogramms
       kalibriert werden.
     *)

END FischerInterface.

Das Implementation Module enthält die Implementierung:

Code: Alles auswählen

IMPLEMENTATION MODULE FischerInterface;

  (* Low-Level-Hardwareschnittstelle zum fischertechnik-computing-
     Interface. *)

  (* UPDATES:
     14.07.1989 sf   SwitchStatus f„llt nicht mehr so leicht auf prellende
                     Schalter herein, da ein Schalterzustand erst dann als
                     gltig angesehen wird, wenn zweimal sofort hintereinander
                     der selbe Zustand gemessen wird.
     15.07.1989 sf   Erkennung von Schalterprellung verbessert.
     22.07.1989 sf   InstallTermProc (Init) eingefhrt.
     24.02.1990 sf   Portadressen fr Geosoft-Laptop ge„ndert. Die Motoren
                     und Schalter waren verkehrt herum durchnumeriert;
                     korrigiert.
     09.04.1992 sf   Anpassung an Modula-2 V4.0.
     13.10.1992 sf   Die Port-Adressen werden selbst berechnet. Das Interface
                     kann an eine beliebige parallele Schnittstelle von LPT1:
                     bis LPT4: angeschlossen sein. Dies wird ber ein IniFile
                     gesteuert.
     02.08.1994 sf   Beim 486/66DX2 festgestellt: Die Schalter werden nicht
                     sauber abgefragt - der in Modula-2 programmierte PC ist
                     (selbst in einer Windows-DOS-BOX) zu schnell fr das
                     Interface. Im IniFile ist eine neue Variable
                     "ProcessorSpeed" mit einem LONGINT-Wert definiert.
                     Die neue Prozedur KleineVerzoegerung bremst das ganze
                     damit ein biáchen.
   *)

  FROM SYSTEM IMPORT DISABLE, ENABLE, INB, OUTB;

  FROM RTSTerm IMPORT InstallTermProc;

  FROM Delay IMPORT Delay;

  FROM IniFiles IMPORT ReadIniFileAlone, IniMessage, IniAction;

  FROM Strings IMPORT CompareStr;

  FROM NumberConversion IMPORT StringToLongInt;

  TYPE
    BitInByte = [0..7];
    Byte = SET OF BitInByte;

  VAR
    PrinterPort, BusyPort: CARDINAL;
      (* Adresse des Printerports und des Busy-Ports der verwendeten
         Parallel-Schnittstelle. *)
    MotorStatus: Byte;
      (* Angaben ber den aktuellen Zustand aller Ausg„nge. *)
    ProcessorSpeed: LONGINT;
      (* Je h”her die Zahl (aus FISCHERI.INI), desto l„nger wird dem
         Interface an manchen Stellen ber die Prozedur KleineVerzoegerung
         Zeit gelassen. *)

  PROCEDURE KleineVerzoegerung;

    (* Wartet ein kleines biáchen. *)

    VAR i: LONGINT;

  BEGIN
    i := 0;
    WHILE i < ProcessorSpeed DO
      INC (i)
    END
  END KleineVerzoegerung;

  PROCEDURE SetOutput (Status: Byte);

    (* Setzt Ausgaberegister entsprechend Status.

       in:   Status   Die Information ber den gewnschten Zustand aller
                      Ausg„nge.
     *)

    VAR Bit: BitInByte;

  BEGIN
    MotorStatus := Status;
    DISABLE;
    FOR Bit := 0 TO 7 DO
      IF Bit IN Status THEN
        OUTB (Byte {5, 4, 2}, PrinterPort);
        OUTB (Byte {5, 4, 3, 2}, PrinterPort)
      ELSE
        OUTB (Byte {5, 4}, PrinterPort);
        OUTB (Byte {5, 4, 3}, PrinterPort)
      END
    END;
    OUTB (39H, PrinterPort);
    ENABLE
  END SetOutput;

  (* Exportierte Prozeduren: *)

  PROCEDURE Init;

    (* Schaltet alle Ausg„nge inaktiv. *)

  BEGIN
    SetOutput (Byte {})
  END Init;

  PROCEDURE SetMotor (n: Motor;
                      Dir: Direction);

    (* Schaltet einen der Motoren.

       in:   n     Die Nummer des anzusteuernden Motors.
             Dir   Die gewnschte Drehrichtung bzw. Polung des Ausgangs.
     *)

    VAR MotorIndex, DirByte: Byte;

  BEGIN
    CASE n OF
      1:
        MotorIndex := Byte {7, 6} |
      2:
        MotorIndex := Byte {5, 4} |
      3:
        MotorIndex := Byte {3, 2} |
      4:
        MotorIndex := Byte {1, 0}
    END;
    CASE Dir OF
      off:
        DirByte := Byte {0..7} |
      left:
        DirByte := Byte {1, 3, 5, 7} |
      right:
        DirByte := Byte {0, 2, 4, 6}
    END;
    SetOutput ((MotorStatus + MotorIndex) / (DirByte * MotorIndex))
  END SetMotor;

  PROCEDURE SwitchStatus (n: Switch): BOOLEAN;

    (* Fragt einen Schalter ab.

       in:   n           Die Nummer des abzufragenden Schalters.
       out:   (RETURN)   TRUE genau dann, wenn der Schalter auf Durchgang
                         geschaltet ist bzw. die entsprechende
                         Eingangsleitung des Interfaces auf +5 V liegt).
     *)

    PROCEDURE ActualStatus (n: Switch): BOOLEAN;

      (* Fragt den Schalterzustand ab. *)

      VAR
        Bit: BitInByte;
        SwitchByte, InputByte: Byte;

    BEGIN (* ActualStatus *)
      SwitchByte := Byte {};
      DISABLE;
      OUTB (32H, PrinterPort);
      KleineVerzoegerung;
      OUTB (3AH, PrinterPort);
      FOR Bit := 7 TO 0 BY -1 DO
        KleineVerzoegerung;
        INB (InputByte, BusyPort);
        IF 7 IN InputByte THEN
          INCL (SwitchByte, Bit)
        END;
        OUTB (30H, PrinterPort);
        KleineVerzoegerung;
        OUTB (38H, PrinterPort)
      END;
      ENABLE;
      RETURN n - 1 IN SwitchByte
    END ActualStatus;

    VAR s1, s2: BOOLEAN;

  BEGIN
    (* Prellen abfangen: *)
    s1 := ActualStatus (n);
    s2 := ActualStatus (n);
    WHILE s1 # s2 DO
      Delay (1);
      s1 := s2;
      s2 := ActualStatus (n)
    END;
    RETURN s2
  END SwitchStatus;

  PROCEDURE AnalogStatus (n: AnalogInput): CARDINAL;

    (* Fragt einen der Analog-Eing„nge ab.

       in:    n          Die Nummer des abzufragenden Eingangs.
       out:   (RETURN)   Eine Zahl, deren H”he in einem linearen Zusammenhang
                         mit dem an dem Analogeingang n anliegenden
                         Widerstand steht. Sonst ist ber diese Zahl nichts
                         bekannt.

       Bevor diese Funktion fr eine Steuerung verwendet werden kann, muá der
       m”gliche Wertebereich durch geeignete Maánahmen des Anwenderprogramms
       kalibriert werden.
     *)

    CONST max = MAX (CARDINAL);

    VAR
      count: CARDINAL;
      InputByte: Byte;

  BEGIN
    count := 0;
    DISABLE;
    CASE n OF
      1:
        OUTB (0A0H, PrinterPort) |
      2:
        OUTB (090H, PrinterPort)
    END;
    OUTB (38H, PrinterPort);
    REPEAT
      INB (InputByte, BusyPort);
      INC (count)
    UNTIL NOT (7 IN InputByte) OR (count = max);
    ENABLE;
    RETURN count
  END AnalogStatus;

  PROCEDURE UseLPTPort (PortNumber: CHAR);

    (* Berechnet die Portadressen des angegebenen LPT-Ports ("1" - "4"). *)

    VAR LPTPorts [40H:08H]: ARRAY ["1".."4"] OF CARDINAL;

  BEGIN
    PrinterPort := LPTPorts [PortNumber];
    BusyPort := PrinterPort + 1
  END UseLPTPort;

  PROCEDURE HandleIniMessage (VAR E: IniMessage);

    (* Behandelt das IniFile. *)

    VAR ok: BOOLEAN;

  BEGIN
    WITH E DO
      CASE Action OF
        StartSectionRead:
          interested := CompareStr (OldSection, "FischerInterface") = 0 |
        ReadEntry:
          IF (CompareStr (EntryName, "LPTPort") = 0)
            AND (EntryInfo [0] >= "1") AND (EntryInfo [0] <= "4")
            AND (EntryLen = 1) THEN
            UseLPTPort (EntryInfo [0])
          ELSIF CompareStr (EntryName, "ProcessorSpeed") = 0 THEN
            StringToLongInt (EntryInfo, ProcessorSpeed, ok);
            IF NOT ok THEN
              ProcessorSpeed := 0
            END
          END
      END
    END
  END HandleIniMessage;

  PROCEDURE InitPortAddresses;

    (* Bestimmt die zu verwendenden Portadressen. *)

    VAR ok: BOOLEAN;

  BEGIN
    UseLPTPort ("1");
    ProcessorSpeed := 0;
    ok := ReadIniFileAlone ("FISCHERI.INI", HandleIniMessage)
  END InitPortAddresses;

BEGIN (* FischerInterface *)
  InitPortAddresses;
  Init;
  InstallTermProc (Init)
END FischerInterface.

Vielleicht lässt sich ja das eine oder andere daran ablesen.

Viele Grüße,
Stefan

[fishfriend]

Hallo...
Ehrliche Meinung: So wird das nichts.
Um wieviel ändert sich das SIgnal am Port?
Tja, da geht es schon los. Man muss das messen.
Bei den Prozessor-Frequenzen kann es sein, dass da schon viel viel mehr NOPs rein müssen.
Manchmal macht man auch leere Rechnungen nur um die Zeit zu schinden.
Man kann das auch überschlägig Rechnen wieviel Zeit pro NOP verbraten wird. Sooo viel ist das bei ein, zwei nicht sein.

Ich meine mich dunkel dran zu erinnern, dass man auch bestimmten Prozessen mehr Prioitäten zuweisen kann. Aber ob und wie das bei WIn 95 geht k.A. mehr.
BTW Welche Win95 nutzt du denn? Ich meine da gibt es verschiedene Versionen.

Es kann sein, dass noch ander Mechanissmen da reinspielen. Z.B. das die Pipe also die Reihenfolge der nächsten Befehle für den Prozessor "überwacht" wird und bei den NOPs ein anderer Prozess eingeschoben wird.
Oder das die NOPs vom Compiler wegoptimiert werden. usw.

Ich würde dir empfehlen so einen billigen USB Stick zu holen und mal die Ports richtig messen. Ob nun die Wartezeiten überschritten werden und das Interface abschaltet glaub ich jetzt nicht, aber zumindest kannst du sehen, ob die Ports sich langsam genug ändern oder ob man da noch mehr NOPs (10...30...50... NOPs) reinmachen muss.
Ich würde Wetten das luckylogic im Treiber selbst über Windows Events oder über einen anderen Timer läuft und nicht über NOPs. Zumindest würde ich das so machen.

Man könnte es auch noch etwas anders machen, indem man eine Frequenz erzeugt, in dem man eine Endlosschleife programmiert und den I/O toggelt. Es gibt auch kleine Hand-Voltmeter die Frequenzen messen können. Ich hab auch so welche. Kann ja sein, das deins das auch kann.
Mit freundlichen Grüßen
Holger

[FiTeN3rd]

Hallo zusammen,

im Grunde ist die Idee mit den NOPs ja richtig - es frisst Zeit. So, wie markpot4 das beschrieben hat, geht das ziemlich sicher nicht. Dazu ein paar Gedanken / Fragen.

Wie setzt Du das um?
Man kann die NOPs in einem Basic-Programm mit POKE "an ihre Stelle bringen". Das ist dann relativ aufwändig (OP-Codes sämtlich einzeln an ihre Stelle poken) und was ist dann mit dem ganzen Rest des Programmes?
Oder verwendest Du etwa MASM von Kleinst und Weich nebst Linker oder etwas Vergleichbares?
Durch die NOPs wird das Assemblerprogramm länger. Zumindest unter GWBasic bleiben maximal 64 Bytes bis zum "oberen Ende".
Allgemein: es werden ja auch die Einsprungsadressen nach dem geänderten Code verschoben. Wenn dann die "alten" Einsprungadressen angesprungen werden, dann steht da ja "irgendwas"-es ist dann auch möglich dass das Programm oder die ganze Umgebung abstürzt.

Nach wie vor glaube ich, dass des Pudels Kern in der Windows-Umgebung steckt. Hier wird vieles durch Interrupts gesteuert, und es ist nur bedingt bis gar nicht nachvollziehbar, ob irgendein "feuernder" Interrupt nicht ein sorgsam gestricktes Timing durcheinanderbringt. Selbst in der DOS-Umgebung werden Interrupts jeweils nach Einsprung mit CLI gesperrt und später mit STI wieder freigegeben.
Bitte beachten: eine DOS-BOX in Windows darf nicht mit einer "uralten" DOS-Umgebung verglichen werden. Bei der DOS-BOX ist immer ein gut Teil Windows noch enthalten.

Es gab einmal eine Version von UMFISH.ZIP mit einer DLL, die die Programmierung unter C (und PASCAL ?) erleichtert hat. Leider ist die frühest habhafte Variante davon heute (seit 2009) schon für den TX-Controller umgeschrieben, ältere Version/en sind im "Nach Server Zusammenbruch Nirvana" verschwunden (fehlschlagende Links aus der ft:pedia heraus). Sollte jemand das lesen und noch einen funktionierenden Link haben: bitte mitteilen!

Und noch einmal einen anderen Ansatz. Unter https://www.nachthacker.de/ findest Du eine "FTToolbox". Die habe ich selber noch nicht ausprobiert, weil ich den "reine DOS Umgebung" Pfad eingeschlagen und bislang erfolgreich beschritten habe. Die Programmierung findet in C statt - was relativ einfach nach Turbo-Pascal oder Delphi zu übertragen sein sollte. Ziemlich sicher funktioniert das aber nicht in 64 bit Umgebungen - dieses Problem solltest Du mit W98 aber nicht haben.

Zum Thema Messen. Für meine Versuche habe ich das LabNation Mini-Oszilloskop SmartScope (200 bis 400 Euro) verwendet. Das Ding hat einen 8 kanaligen Digitalen Logger und ist für Timing-Messungen hervorragend geeignet. Das im Original-Handbuch meines Interface dargestellte Timing-Diagramm konnte ich damit exakt nachstellen und untersuchen. So bin ich übrigens auf diese Pegel-Geschichte gestoßen - ich habe die Puls-Leitung analog nachgemessen.

Wenn Du Interesse an einer Messkampagne unter Hobbyisten hast, schreibe mir bitte eine PN. Ein Besuch meinerseits ist natürlich ein wenig abhängig von der zu überwindenden Distanz . . .

Freundliche Grüße aus Braunschweig,

Matthias (fiten3rd)