Hi, hab ein altes DOS-Programm, welches mit serieller Schnittstelle arbeitet, zu allem Überfluss auch noch mit Hardware-Handshake (zwingend für die korrekte Funktion nötig), also ist der Handshake nicht abzuschalten. Unter Win2000 läuft das Prog, unter WinXP wie erwartet nicht mehr, d.h. das Prog selbst läuft, aber auf der Schnittstelle kommt Murks. Ich sehe es jetzt nicht ein, bloß wegen EINEM Programm noch 2000 draufzupappen. Kennt jemand ne Möglichkeit, wie ich das unter XP trotzdem noch ans laufen bekomme? Virtuelle PCs hab ich noch nicht probiert, weil ich hoffe, dass es noch andere einfachere Möglichkeiten gibt... Ralf
Das ist merkwürdig, da sich XP und Windows 2000 nur in kleinen Details unterscheiden. Das ganze DOS-Emulationsgrkröse (NTVDM) ist eh weitestgehend gleichgeblieben, zu erwarten wäre allenfalls das umgekehrte Verhalten (keine Funktion unter 2000, aber Funktion unter XP). Daher ist "läuft wie erwartet nicht mehr" verwunderlich. Ursache des Problems ist die Art und Weise, mit der DOS-Programme die serielle Schnittstelle "befummeln"; nämlich fast ausschließlich mit direkten Hardwarezugriffen, die mehr oder weniger geschickt durchgeführt werden. Da nicht nur die serielle Schnittstelle selbst, sondern auch noch der Interruptcontroller "befummelt" wird, hat die Hardwareemulation von Windows NT (um nichts anderes handelt es sich hier) eine ganze Menge zu tun. Wenn also das Programm glaubt, sich mit der Schnittstelle zu unterhalten, befummelt es in Wirklichkeit ein idealisiertes Abbild, das von der NTVDM zur Verfügung gestellt wird, und das wiederum versucht aus dem "Gefummele" schlau zu werden und daraus Informationen abzuleiten, die dann wiederum an den Devicetreiber der seriellen Schnittstelle weitergeleitet werden können. Dasselbe geschieht mit dem Gefummele für den Interruptcontroller; wobei die Zugriffe auf diesen nie bei irgendwelcher Hardware ankommen, sondern in irgendwelchen Virtualisierungsschichten abgefangen werden. Nun kann die Virtualisierung durch besonders kreative Art und Weise des "Befummelns" durcheinandergebracht werden, möglichweise liegt hier ein derartiges Problem vor. Der Hardwarehandshake selbst ist mit ziemlicher Sicherheit nicht die Ursache des Problemes, der wird eh' von Deinem DOS-Programm in Software umgesetzt, da die Standardschnittstellenhardware des PCs gar kein "echtes" Hardwarehandshake kann (wenn denn nicht explizit Funktionen des neueren 16550 genutzt werden, die Standardhardware ist aber immer noch der steinalte 8250). Ganz anders sieht die Angelegenheit aus, wenn Treiber wie giveio installiert sind, dann ist es eigentlich nur eine Frage der Zeit, bis das System sich mit einem BSOD verabschiedet. Bei I/O-Operationen, die keine Interruptverarbeitung erfordern, wie die beliebte Parallelschnittstelle, da mag diese Vorgehensweise noch angehen, aber bei allem aufwendigeren wie der seriellen Schnittstelle, der Verarbeitung von Interrupts oder gar der Timerprogrammierung - Finger weg. Nun bietet Windows XP verschiedene Emulationseinstellungen für DOS-Programme an (um die zu Gesicht zu bekommen, muss eine Verknüpfung auf das DOS-Programm angelegt werden. Auf den Eigenschaftsseiten "Programm", "Speicher", "Kompatibilität" und "Sonstiges" gibt es einiges, was anzusehen lohnenswert sein kann. (Bei "Programm" ist es der Knopf "Erweitert", der die "kompatible Timer-Emulation" anbietet, vielleicht auch ein Problem?) Diese Einstellungen hatte auch schon Windows 2000 und auch schon Windows NT 4.0, nur jeweils weniger ausführlich. Was macht denn das DOS-Programm so wichtiges, daß das noch verwendet werden muss?
FreeDOS von Diskette booten wäre noch eine Möglichkeit, oder vielleicht einen DOSEmu unter Knoppix. Ich hatte mal versucht, das DOS-Programm von Texas Instruments zum "Gas Gauge"- Batteriemonitor BQ20xx laufen zu lassen - keine Chance. schon unter Windows 98 muß man in den echten DOS7-Betrieb umschalten, das DOS-Fenster geht nicht.
>> Was macht denn das DOS-Programm so wichtiges, daß das noch verwendet >> werden muss? Es handelt sich um eine Testsoftware, die in unserer Firma verwendet wird. Die Software ist von einem Programmierer unserer Firma geschrieben (ich glaub in Pascal). Er supportet sie aber nicht mehr. Also ist ein Umbau auf XP ausgeschlossen. Ich versuch mal, das Problem (wie ich es sehe) noch genauer zu erläutern. Es wird mit einem RS232-RS485-Umsetzer gearbeitet. Mittels CTS-Leitung wird bei 2-Draht-Betrieb der RS485 die Richtung angegeben. Und das funktioniert offenbar nicht richtig unter XP, wohl aber unter 2000. Meine Vermutung ist ein Timing-Problem, nämlich dass die CTS-Leitung unter XP nicht so schnell wie unter 2000 angesprochen wird. Daher sendet ein an die RS485 angeschlossenes Gerät bereits, obwohl der Umsetzer noch nicht auf Lausch-Betrieb ist... Ralf
Das ist wie gesagt sehr merkwürdig, weil sich zwischen NT5.0 und NT5.1 die DOS-Emulation sogar eher etwas verbessert haben sollte. Frage am Rande: Das ist aber dieselbe Rechnerhardware, auf der nur ein neues OS installiert wurde, oder ist das auch ein neuer Rechner? Eine Abhilfe für diese Ansteuerung von RS485-Umsetzern ist die Verwendung von dafür geeigneten Schnittstellenbausteinen wie den UARTs von Oxford Semiconductor, die man auf einigen PCI-Seriell-Karten findet. Die beherrschen eine automatische Sender/Empfängerumschaltung (wenn das Senderegister und der Sendefifo des Schnittstellenbausteines leer ist, wird eine Handshakeleitung umgeschaltet). Das übrigens beherrscht sogar der USB-Seriell-Konverterbaustein FT232 von FTDI, der hat einen eigenen Steuerausgang für die RS485-Senderumschaltung. Davon wird zwar das DOS-Programm nichts mitbekommen, aber möglicherweise funktioniert diese Lösung. Daß die Schnittstellenhardware selbst gar nichts mehr mit der Standard-8250 zu tun hat, ist ja aufgrund der NTVDM-Virtualisierung eh unbedeutend; es wird wohl nur nötig sein, die DOS-Gerätenamen der seriellen Schnittstellen neu zuzuordnen und im Gerätemanager bei den Oxford-Schnittstellen die Hardware-RS485-Unterstützung zu aktivieren. Aber das ist eine Notlösung, die eigentlich gar nicht nötig sein sollte, da ja XP und Windows 2000 sich äußerst ähnlich sind. Auf dem XP-Rechner sind nicht noch irgendwelche nebenher laufenden Dinge aktiv, die Rechenzeit verbraten (Onlinevirenscanner etc.)? Das Pascal-Programm habt Ihr ja wohl schon offensichtlich gepatcht, da es sonst Rechnern der Pentium-Klasse mit dem beliebten Runtime-Error 200 aussteigen dürfte ... Zur Klarheit: Was für ein Rechner ist das, auf dem das XP installiert ist? Der, auf dem schon Windows 2000 lief oder ein anderer? Wie ist der Rechner ausgestattet? Was für eine serielle Schnittstelle ist das? Onboard-Schnittstelle, PCI-Karte oder gar USB-Adapter?
Also, auf meinem Arbeitsrechner lief noch nie was anderes ausser XP. Aber was ist weiss ist, dass Kollegen vor längerer Zeit ebenfalls neue Rechner bekamen, zuerst mit XP. Nachdem die Kollegen feststellten, dass es mit XP nicht einwandfrei geht, haben sie sich 2000 draufpappen lassen. Damit gehts wie gesagt, somit ist es nicht zu einer Änderung der Hardware gekommen... Ob da mal was gepatcht werden musste, weiss ich nicht... Dann wars wohl doch kein Pascal... Ralf
Schau dir mal die Einstellungen der Schnittstelle vom XP und 2000 Rechner an, sowohl im Gerätemanager als auch mit mode Kommando. Kann sein das von Windows deine Schnittstelle eine andere "Vorinitialisierung " besitzt und die Initialisierung der Schnittstelle durch dein Dosprogrammes nicht sehr "vollständig" ist und es so zu unterschiedlichem Verhalten kommt. Schau dir das ganze dochmal am Oszi an.
Evtl. auch mit dem Dosbox-Emulator, der kann auf serielle Schnittstellen zugreifen. http://sourceforge.net/projects/dosbox
Was spricht dagegen, von Diskette zu booten? Da passt wahrscheinlich neben den Startdateien auch noch Dein Pascal-Programm drauf.
"s ist merkwürdig, da sich XP und Windows 2000 nur in kleinen Details unterscheiden. " Doch das ist so! Ich hatte das auch: Zugriffsprobleme unter XP mit Programmen, die unter 2000 korrekt liefen. Ich habe mal mit einem Multiportserver gewerkelt und dessen Hersteller hat ebenfalls keine Treiber für XP ausgegeben, sondern ausdrücklich W2k empfohlen!
Hi Ich habe mit meinem Projekt genau die selben Erfahrungen gemacht. http://www.mikrocontroller.net/forum/read-8-401498.html#new Die diversen Windows Versionen scheinen die serielle Schnittstelle unterschiedlich zu handeln. Der COM Port scheint bei neueren Betriebsystemen sehr "stiefmütterlich" behandelt zu werden. (Sie haben wohl mit den Bugs auf der USB Schnittstellen Seite genug zu tun) Jetzt habe ich ein 3GHz Rechner und es kommt mit 38400 Baud unter Windows XP zu Datenverlust (!) Ich bin ja auch nicht gerade der super Programmierer und vielleicht liegt es zum Teil auch an mir, aber es stimmt mich schon nachdenklich, dass ich meine Software bei jeder neuen Betriebssystem Version, ja manchmal sogar von SP zu SP neu überarbeiten muss. (Man schaue sich nur mal auf der Adobe HP die unterschiedlichen Acrobat Reader Versionen an!) Das kann sich ein Kleinbetrieb kaum mehr leisten. Ich bin froh um jeden Tip, um mehr Klarheit über die serielle Schnittstelle zu bekommen und wünsche Dir Ralf, dass Du das Problem noch in den Griff kriegst. Hast Du die Infos von Rufus schon probiert, das hat bei mir auch schon geholfen: >Nun bietet Windows XP verschiedene Emulationseinstellungen für >DOS-Programme an (um die zu Gesicht zu bekommen, muss eine >Verknüpfung >auf das DOS-Programm angelegt werden. Auf den Eigenschaftsseiten >"Programm", "Speicher", "Kompatibilität" und "Sonstiges" gibt >es einiges, was anzusehen lohnenswert sein kann. >(Bei "Programm" ist es der Knopf "Erweitert", der die "kompatible >Timer-Emulation" anbietet, vielleicht auch ein Problem?) Gruss Andy
Hallo, ich habe das gleiche Problem. Unter W2000 laufen alle Dosprogramme die die RS232 bedienen ohnen Probleme. Selbst auf einem 90MHz Pentium mit WinNT absolut problemlos. Ab XP gibt es nur Probleme. Auch ich wäre dankbar für ein Lösungsweg, da es mit sicherheit nicht am Programm liegt. gruss Josef
2 Dinge sollten man beachten (beim Schreiben von Programmen fuer die serielle Schnittstelle): 1. Das Schlechte an den _outp und _inp ist, das sie wirklich nur mit DOS, W95/98 funktionieren. W2k und XP KOENNTEN damit zurechtkommen, aber fuer diese OS empfiehlt MS die Verwendung von ReadFile und WriteFile. Diese Funktionen funktionieren auch ohne Probleme unter W95/98. 2. Die Bedienung der seriellen Schnittstelle ist nicht so simpel wie es viele C/C++-Sourcen vorgaukeln. Einfach nur CreateFile und dann ReadFile is' nich! Daran verrecken viele Programme und es kommt zu "unerklaerlichen" Verhalten" (siehe die Posts weiter oben). Hat man aber schon ein fertiges Programm und muss es einsetzten, so bleibt nichts weiter uebrig, es bei Problemen auf anderen Systemen a) neu zu schreiben oder b) es wieder auf dem Orginalsystem einzusetzen. Blackbird
Also der Dosemulator hängt das Programm auf. Da direkt auf die Schnittstelle zugegriffen wird (Interrupt und I/O) wird dieses wohl micht sauber unterstützt. Oder ich mache da noch etwas falsch? Aber viel einzustellen ist da ja nicht. Ich muss doch XP irgend wie dazu bewegen sich wie W2K zu verhalten. Eventuell anderen Treiber? Gruss
Ich habe auf wxwidgets umgesattelt. Damit umgeht man viele der betriebsystemtypischen Anpassungen und unter Linux laueft es auch gleich. Eine Anleitung von mit zum Thema Portpürogrammierung gibt es bei dem Bereitsteller der seriellen Lib für wxWidgets -> iftools.com
> Also der Dosemulator hängt das Programm auf.
In der dosbox.conf muss man einstellen welchen COM-Port es zu verwenden
gilt. I/O und Interrupt wird komlett emuliert, allerdings hat 0.65 noch
einen Bug in der seriellen Schnittstelle. Der tritt dann auf wenn
gleichzeitig gesendet und empfangen wird (die TX-Interruptquelle wird
fälschlicherweise immer gelöscht wenn ISR gelesen wird) Oder ein
anderer Teil der Emulation funktioniert noch nicht richtig. Ich habe
eine korrigierte Version, kann ich hochladen wenn erwünscht.
Im Programm wird gleichzeitig empfangen und gesendet. Ich habe in der Dosbox.con folgenden Eintrag: serial1=directserial realport:com1 Sollte also richtig sein? Wäre nicht schlecht die die korrigierte Version auszutesten.
serial1=directserial realport:com1 ist richtig. Die Datei am besten in das Dosbox-Verzeichnis kopieren. Fehlende DLL-Dateien gibts bei Google. Bei höheren Baudraten den cycles-Wert in der config.-Datei auch mal erhöhen und auf das zweite Konsolenfenster achten. Das alte S5-Programm läuft bei mir hier problemlos (mit AG), auch schon mit der 0.65. Heißt natürlich nicht das alle Programme funktionieren.
Also jetzt scheint die Dosbox zu laufen. Kann allerdings erst Dienstag den richtigen Test maschen. Ich melde mich dann ob es geklappt hat. Erst einmal Danke! Gruss Josef
Hallo, scheint wirklich wunderbar zu funktionieren!!!! Danke für den Tip
Alles super, wie bekomme lasse ich denn bei der DosBox das Satus Windows verschwinden?
Hallo! Bei mir funktioniert die dosbox-sermod.exe nicht richtig. Ich hab schon einige zlib1.dll ausprobiert aber es kommt immer die Fehlermeldung "Die Ordnungszahl 53 wurde in der DLL "zlib1.dll" nicht gefunden". Kann mir da bitte jemand helfen? Vielen Dank im Voraus! mfg Martin
Wow, da ist ja ganz schön was los. Sorry, dass ich erst jetzt mal wieder antworte, war ziemlich beschäftigt, und leider konnte ich an der seriellen Problematik noch nicht weiter arbeiten :-( Werd mir die ganzen Beiträge mal in Ruhe ansehen, und meld mich dann nochmal... Ralf
DLLs im Anhang. @Ralf: Nicht zu viele Hoffnungen machen, bei zeitkritischen Anwendungen kann der Emulator durchaus versagen.
Jetzt habe ich doch noch ein Problem. Wenn das Dos - Programm das erste Zeichen herausschickt wird vor diesem Zeichen ein 0xff geschickt. Das führt manchmal zu Problemen. Kann ich das irgend wie abstellen?
Da muss ich wohl nochmal ran... ist mir schon mal aufgefallen, habe es dann aber aus den Augen verloren.
Noch ein weiteres Problem haben ich. Auf COM1 läuft alles ohne Probleme, jedoch COM2 macht ständig Ärger. Schickt wohl irgendwann ein zusätzliches Zeichen zur Gegenstelle. Die stürzt dadurch ab. Ich benötige COM1 + COM2. Gibt es dort Einstellungen die ich eventuell noch vornehmen kann?
Hatte ich noch vergessen. der Auzug aus der CONF Datei: serial1=directserial realport:com1 irq4 serial2=directserial realport:com2 irq3
Hmm, die beiden COM-Ports werden nicht unterschiedlich behandelt, es ist entweder ein Hardwareproblem (USB? einige Adapter scheinen schlecht implementiert zu sein) oder ein Problem mit der DOS-Software (evtl. ein anderes Emulationsproblem). Die IRQ-Einstellungen sinn übrigens default und können deswegen weggelassen werden. Das mit dem überschüssigen Zeichen konnte ich nicht nachvollziehen... aber evtl. habe ich den Bug schon überfahren.
Ich habe keine USB-RS232 Schnittstelle! Sicherlich ist die Behandlung der COM1 unterschiedlich zur COM2. Interrupt und I/O. Dass sollte jedoch das einzigste im DOS Programm sein. Bei der COM1 habe ich immer das Problem wenn ich das Erste Zeichen hersuasschicke wird zuvor ein \0xff geschickt. Bei COM2 ist das offensichtlich auch zwischendurch der Fall. Kann ich den dem DOS Sagen du benutzt COM1, aber in wirklichkeit ist das COM2 ??? Also in der DOSBOX.CONF z.B. serial2=directserial realport:com1 irq4 Das würde mir dan auch genügen, da ich nie zur geleichen Zeit COM1 + COM2 anspreche.
Klar geht das. Auch mit COM9. In der hier angehängten Version auch mit COM10. IRQ und I/O sind verschieden, aber der Rest eines emulierten COM-Ports ist eine Instanz einer Klasse. Ein paar Fehler könnten behoben sein und zusätzlich kann diese hier auch serielle Akivität mitloggen: serial1=directserial realport:com1 dbgtr dbgmd dbgirq dbgreg dbgaux Im Unterverzeichnis capture entsteht dann eine xxx.serlog.txt mit den Daten. Zum Reverse-Engineering dürften aber nur dbgtr (Datenverkehr) und dbgmd (Handshake-Leitungen) hilfreich sein. Dann gibt es noch rxdelay für directserial: serial1=directserial realport:com1 rxdelay:100 d.h. der Anschluß wird 100 Millisekunden warten bevor er einen overrun error auslöst. Bei Dosbox fehlen scheinbar noch einige STIs in den API-Aufrufen wodurch schlecht programmierte Software die Daten nicht rechtzeitig lesen kann. rxdelay schafft da evtl. erst mal Abhilfe.
@*.* Kannst du hier deine veränderten Source-Dateien posten? Oder wirst du die veränderten Dateien dem CVS hinzufügen? Dann könnten auch andere davon profitieren... BTW, warum benötigt deine .exe eine ZLib-DLL? Ansonsten werde ich demnächst ein bischen mit DosBox experimentieren...
Die Dosbox-Entwickler kennen meinen Code, aber da der primäre Zweck der Dosbox Spiele sind kann das einige Zeit dauern bis (wenn überhaupt) es übernommen wird. Der Großteil der seriellen Schnittstelle in 0.65 geht auch schon auf mein Konto. Ich werde das mal rauskramen bzw. eine diff erzeugen, habe aber jetzt gerade keine Lust ;) Ich kompiliere das Programm mit Visual Studio, welches offensichtlich so eingestellt ist die Library dynamisch zu linken. Die 0.65 Release ist mit dem GCC kompiliert mit zlib statisch verlinkt. Dosbox benutzt Zlib für die Screenshots und den Videorecorder. (Nein ich verwende es nicht um deine Dateien komprimiert zu mir zu schicken ;)) Übrigens habe ich für den Parallelport etwas ähnliches, braucht aber den Porttalk-Treiber.
Hallo miteinander. Wir haben einen PC als Programierstation mit der eeprom.exe an COM1. Dies lief mit einem älteren Compaq PC mit WinXP pro SP1 gut. Mit dem neuen Dell PC und WinXP pro SP2 nicht mehr. Nun habe ich mir die DOSBox installiert und damit geht wenigstens das Lesen. Problem ist das Umsetzen der < und > nicht als Zeichen sondern der Datenweitergabe. Schön wäre wenn auch kopie und past geht aber dafür kannn man sich auch ein Script schreiben. Gibt es dafür geänderte Programmdateien? Im voraus schon herzlichen Dank. MfG Tilo Meinhardt
Für Copy&Paste gibt es einen Patch: http://www.qv90.de/?sw&F8=1&CI=1&FI=2 Habe allerdings keine Erfahrungen damit. > < im sinne von "echo 1234 > com1"? Ist eine nicht ausgereifte Ecke.. was funktioniert nicht?
Hallo, danke für den Link. Habe dort ein paar Sachen gefunden. Wir haben hier bestückte Leiterplatten die erkannt werden bzw. auch das auslesen der IC's funtioniert. Nur das Schreiben von Daten aus Dateien. Es geht um Deutung der Symbyle > und < (im Linux Standardeingabe / Standardausgabe). Folgendes Beispiel: D: cd \backup\IOCP-E cd Mem_Mod_SPD_programming EEPROM INFO -I COM1 -s EEPROM WRITE -I COM1 I2C_ROM_5 < IOCP-E_mem_SPD.x EEPROM READ -I COM1 i2c_rom_5 0 0 EEPROM WRITE -I COM1 I2C_ROM_7 < IOCP-E_mem_SPD.x EEPROM READ -I COM1 i2c_rom_7 0 0 Schicke die Daten von der Datei in den Rom (IC).
Erwartet denn "EEPROM" die zu programmierenden Daten via stdin? Das ist bei DOS-Programmen extrem ungewöhnlich.
DESCRIPTION The EEPROM tool was designed to help programing or updating all EEPROMs on a board. Supported are EEPROMs with an I2C-bus or a Microwire(TM) interface, e.g. ID-ROMs on a local I2C-bus, EEPROMs behind an IPMI controller, the SROM of a DEC21554 PCI bridge, and the SROMs of several Ethernet Controllers, e.g. DEC21140, DEC21143, and INTEL82559. It knows three commands: INFO, READ, and WRITE. Data is exchanged in S-record format via standard input and standard output, and can be re-directed from/to a file. If the tool is executed within a terminal window (Solaris, or Windows NT), S-records can be copied directly via Copy/Paste (Ctrl-c/Ctrl-v). The tool provides two operating modes: local and remote. Local means that the tool runs on the target, so it can directly access all EEPROMs via the on-board I2C-bus, or via the PCI bus in case of SROMs which are connected to a PCI device. Remote mode uses a standard serial interface (COM port on PCs, or /dev/cua/x on Work Stations) and a small adapter board to connect an I2C-bus to another system via FORCE COMPUTERS 20-pin I2C-bus connector. It allows to program I2C EEPROMs, e.g. SPDs or ID-ROMs (for BIB) without use of any target software.
Ich glaube es ja, nur ist das halt wirklich selten. Bei der unixoiden Herkunft des Tools ist es natürlich nicht verwunderlich. Probiere mal
1 | type IOCP-E_mem_SPD.x | EEPROM WRITE -I COM1 I2C_ROM_5 |
aus, vielleicht geht das ja auch nicht ... Trotzdem viel Erfolg!
| geht glaub ich gar nicht in der Dosbox. Es existiert zummindest ein feature request auf der Sourceforge-Projektseite. http://sourceforge.net/tracker/index.php?func=detail&aid=602715&group_id=52551&atid=467235 > EEPROM WRITE -I COM1 I2C_ROM_5 < IOCP-E_mem_SPD.x Da kommt er irgendwie durcheinander? Dosbox kann nur 8.3-Dateinamen, also die Datei umbenennen oder IOCP-E~1.x (oder so) tippen.
Hallo, habe mir am Freitag noch Sachen runtergeladen, eingerichtet und getestet. Freitagnachmittag habe ich dann den alten PC außer betrieb genommen. WinXP cmd kann copy and past -> die DOSBox nicht. WinXP cmd kann längere Dateinamen -> die DOSBox nicht. Haben desswegen Batches geschrieben und Dateinamen geändert. Danke für die Links und Tipps. Tilo.
Hallo, Ich habe folgendes Problem. Ich möchte von der DosBOX auf eine I/O Karte zugreifen. Unter XP wird diese aber nicht zugelassen. Gibt es eine Möglichkeit? Gruss Josef
Für die parallele Schnittstelle habe ich (mit Porttalk). Dosbox kann man gut erweitern, C/C++-Kenntnisse vorausgesetzt. Man braucht aber einen Kerneltreiber wie Porttalk. Allerdings geht nur I/O, keine IRQ/DMA/Mem-Ressourcen, außer es findet sich jemand, der einen Treiber schreiben kann der diese Ressourcen an den Usermode weiterleitet.
PS: Die Dosbox muß aber verändert werden, einfach nur Porttalk laden funktioniert nicht.
Hallo,
ich habe ein ähnliches Problem (alte DOS Messsoftware) und bekomme immer
timeouts im Messprogramm. Die Benutzung der "dosbox_sermod2.exe" hat das
Problem leider nicht beheben können. Für Infos über neue
Programmversionen (auch beta) währe ich deshalb sehr dankbar.
aus der dosbox.conf:
serial1=directserial realport:com1 startbps:115200 rxdelay:100
aus der serlog.txt:
COM1: BASE 3f8, IRQ 4
1.000 Port type directserial realport com1
1.000 RTS off.
1.000 DTR off.
1.000 DSR off.
1.000 msr interrupt on.
1.000 RI off.
1.000 CD off.
1.000 msr interrupt off.
978.888 write 0x80 to LCR.
978.888 write 0x1 to THR.
978.889 write 0x0 to IER.
978.889 write 0x3 to LCR.
978.889 write 0xb to MCR.
978.889 RTS on.
978.889 DTR on.
978.889 read 0x0 from RHR.
978.890 write 0x87 to FCR.
978.890 read 0x1 from ISR.
978.891 write 0x0 to FCR.
978.892 write 0x1 to IER.
978.892 read 0x0 from RHR.
978.892 read 0x60 from LSR.
978.892 DSR on.
978.892 msr interrupt on.
978.892 CD on.
978.892 msr interrupt off.
978.892 read 0xba from MSR.
978.898 read 0x60 from LSR.
978.898 write 0x24 to THR.
978.898 tx 0x24 ($)
978.899 read 0x0 from LSR.
978.899 read 0x0 from LSR.
978.899 read 0x0 from LSR.
978.899 read 0x0 from LSR.
.....
(Ich gebe zu, mir fehlt das Wissen um in dem log etwas zu erkennen.)
Für Hilfe / Tipps währe ich sehr dankbar.
Wäre noch wichtig zu wissen, ob LSR wieder auf 0x20 und später auf 0x60 zurückspringt. Zwischendurch probiert es aus, ob ein FIFO vorhanden ist, erkennt aber richtigerweise, dass da keiner ist. Ansonsten wird ein $ gesendet aber Daten kommen hier niemals an, der Ausschnitt ist zu kurz. Bei den Steuerleitungen tut sich aber etwas. Es interessiert mich nicht, wieviele tausend mal LSR mit 0 gelesen wird, die könnte man bis auf eines streichen, aber andere Werte schon. Ist das evtl. ein USB-Wandler? Mal eine echte Schnittstelle probieren. Und/Oder eine niedrigere Baudrate wenn möglich.
Hi, ... danke für die schnelle Antwort. Ich lade eins der kompletten Log-files hier mit hoch. Die serielle Schnittstelle befindet sich fest eingebaut auf der Rückseite eines Dell Laptitude D620 Notebooks und ich denke das es sich um eine "richtige" Schnittstelle und nicht um einen USB Wandler handelt. Daniel
Die kommunizieren eigentlich ganz munter. Wurde DOSBox mit einer Absturz-Fehlermeldung beendet? Dann ist das log unvollständig. Mit Strg+f9 zum Beenden (statt Fenster schließen) sollte das nicht passieren. Sagt das Statusfenster irgendetwas von wegen Fehler? Meine Änderungen sind inzwischen im CVS - neueste Version gibts hier: http://builds.tharos-online.de/ Vielleicht läuft die besser. (kann allerdings kein log erstellen).
Ich habe mir die neuste Version gezogen und noch den Parameter "parity:n" eingefügt. Nun läuft es super. Danke für die schnelle Hilfe!
Die startbps: und parity: werden in den neuen Versionen gar nicht mehr ausgewertet. Die DOS-Software setzt diese normalerweise selbst.
Hallo, wir verwenden DOS-Programme welche mit der COM-Schnittstelle mit peripheren Baugruppen kommunizieren. Da diese Programm unter Win-XP nicht mehr zuverlässig laufen, habe ich den DOSBOX-Emulator V0.65 aufprobiert. in der conf: serial1=directserial realport:com1 irq:4 Im Falle eines der Programme, welches mit der Baudrate 38400 arbeitet, hat es auch prima funktioniert. Nun arbeitet ein Programm mit der Baudrate 28800 Baud. Wenn dies in der DOSBOX gestartet wird, sendet es aber mit 19200 Baud! Dies auch wenn ich mit debug direkt die Divisor HI und LO mit den für die Baudrate korrekten Werte 0(HI) und 4(Lo) eintrage (was das Programm selbst ja auch tut). Wie kann ich die DOSBOX überreden, diese Baudrate einzustellen? Für Tipps wäre ich sehr dankbar.
Inzwischen gibt es die DOSBox 0.70. Wenn das Problem da auch auftritt muss ich wohl nochmal ran...
Angehängte Dateien:
-
dosbox070error.png
59 KB
Hallo, Leider läuft die Dosbox 0.70 nicht, sondern bricht mit der Fehlermeldung siehe Anhang ab.
Anbei noch die erzeugte Fehlerdatei e01_appcompat.txt. Ich hoffe das sagt was aus. Gruß Christian
Riecht nach schlechtem DirectX oder Grafiktreiber... Versuch mal die neueren Builds, die schalten in den Schneckengang anstatt abzustürzen. http://builds.tharos-online.de/
Prima! Die neueste Version läuft! Vielen Dank. Eine Frage noch: kann ein Dos-Programm mittels der DosBox auch auf physikalischen Speicher (Realmode, innerhalb des 1. MB) zugreifen? Gruß Christian
Ich kann es ;) ist aber nur ein Experiment und nicht in den offiziellen Versionen enthalten.
Auch ich stand vor einigen Monaten vor einem ähnlichen Problem: Eine mir bekannt Firma benutzte seit vielen Jahren eine in C geschriebene Software unter DOS, mit der sie auf mehrere NC-Maschinen über die serielle Schnittstelle ihre NC-Programme aufspielen, aber auch verschiedene Maschineneinstellungen parametrieren. Alles erfolgte über einen Laptop mit serieller Schnittstelle. Nachdem dieser nun endgültig defekt war, benutzten wir ein vorhandenes neueres Modell ohne (!) eingebaute serielle Schnittstelle: -USB zu Seriell Adapter angeschlossen -nach mehreren unterschiedlichen nicht erfolgreichen Versuchen (auch mit DOS-Box) VMWare-Player installiert -auf einer vorhandenen VMWare-Workstation eine VM mit MS-DOS und virtuellem COM-Port des Hostrechners (vom USB-Seriell Adapter) als COM-Port für die VM erstellt und auf den neueren Rechner übertragen -und was wir nicht erwartet hatten - im WMWare-Player läuft es bis heute ohne irgendwelche Probleme ! Ist sicherlich auch von der benutzten Software abhängig, aber einen Versuch allemal wert. MfG
Mein Dad ist Funktechniker und arbeitet mit Motorola Funkgeräten.. leider läuft die Software zum Auslesen und Programmieren der Geräte nur anständig unter DOS. Neuere Notebooks haben keine Serielle Schnittstelle mehr die zwingend erforderlich ist.. nachdem ich nun hier die Beiträge gelesen habe und denke das ich ein ähnliches Problem habe, würde es mich intressieren ob jemand schon Erfahrungen mit dieser Software-Lösung gemacht hat: http://www.adontec.com/ Da gibts den Comm Extender und bietet folgende Möglichkeiten (Auszug der Webseite): DOS und Windows 16bit Kommunikations-Programme unter Windows 2000 und Windows XP Der COMM-Extender ermöglicht 16bit Programme, welche direkt auf die serielle Hardware zugreifen, ohne Änderungen unter Windows 2000 und Windows XP auszuführen. Mit COMM Extender ist es einfach "alte" DOS Kommunikationsprogramme unter Windows zu starten. Der COMM-Extender erkennt und nutzt Standard-Schnittstellen wie COM1 und COM2, serielle Schnittstellen auf einer PCI Karte, serielle Schnittstellen auf USB Adapter oder Ethernet Server. Nahezu jede serielle Schnittstellen, die unter Windows sichtbar ist, ist erreichbar. Der COMM-Extender arbeitet vollständig im Hintergrund. Es gibt keine Interaktion mit dem Benutzer. Sofort nach Installation der Software wird eine Standard-Konfiguration erstellt und die 16bit Programme können gleich ausgeführt werden. Es ist kein "reboot" von Windows notwendig. Die Standard-Konfiguration kann einfach an die eigene Bedürfnisse angepasst werden. Klingt ja alles ganz gut.. ich kam auch noch nicht dazu die Testversion aus von der Website zu probieren... da wir nun ein neueres Notebook mit USB/Seriell Adapter verwenden wollen.. die aktuelle Dosbox werde ich auch mal testen.. (ohne Adapter) sowie die VMWare und VirtualBox von Innotek.
Die Motorola-Funkgeräte scheinen ein (für die Emulation) ungünstiges Protokoll zu fahren. RX und TX sind direkt an der Schnittstelle verbunden und werden als "Open Collector" weitergeführt. Das Timing mit dem Windows-Treiber ist aber nicht so genau, dass der Emulator den richtigen Registerzustand für diesen Spezialfall bereitstellen könnte. Bisher hatten die Benutzer da mit der DOSBox nur Teilerfolge. Ich hatte auch mal eine spezielle Ausführung gemacht aber die Erfolge waren auch da durchmischt.
Wenn "Murks" ankommt, scheint die Kommunikation ja schonmal zu funktionieren, denn wenn nicht, käme gar nix an. Daher einfach mal mit den Parametern der Comports spielen ....
Hi! Wir benutzen auch die DosBox und haben folgendes Problem: Wir wollen auf eine Serielle Schnittstelle zugreifen und ein UP/Download fahren. (Berger Lahr Steuerung Serie 300) DosBox erkennt die Schnittstelle und öffnet sie auch, jedoch zeigt er dann im Überwachungsfenster einen "Overrun" an und wir bekommen die Fehlermeldung: "Unbekannte Datei empfangen" , "ABS Datei kann nicht geöffnet werden" oder wir bekommen einen EEMPROM Fehler. Der Login funktioniert aber (teilweise wenn die anderen Fehler nicht bzw erst später auftauchen) und einmal haben wir auchschon was geupt (Freudensprung). Änderungen die wir an der CFG vorgenommen haben waren: -serial1=directserial realport:com3 rxdelay 100 -serial 3 bis 4 als disabled -serial 2= dummy -serial 1=directserial Weiss einer zufällig wie man dieses Datengefummel regeln kann? P.s. haben schon viele DosBox Versionen durch von 0.65, sermod 1+2, bis zur Version vom 31.07.07 Über kompetente Anregung würde ich mich sehr freuen =) Danke
COM3? Ist das ein USB-Port? Wie siehts mit der CPU-Auslastung aus? Die DOSBox sollte nie 100% ziehen. Bei einem Dualcore sind das evtl. 50% Die komplette Zeile mit dem Overrun wäre auch interessant. Macht core=dynamic full normal einen Unterschied?
Oft liegt es auch an falsch konfigurierten COM Port Einstellungen in der Systemsteuerung. Wenn auch nicht immer, sollte man aber dennoch diese Werte überprüfen und ggf. anpassen.
@Der Hubert: Die Baudraten usw. werden von den meisten Anwendungsprogrammen selbst gesetzt.
CONFIG:Loading primary settings from config file dosbox.conf MIDI:Opened device:win32 Serial1: Opening com3 Serial1: Errors occured: Framing 0, Parity 0, Overrun 1 (IF0:0), Break 0 Serial1: Errors occured: Framing 0, Parity 0, Overrun 1 (IF0:0), Break 0 Serial1: Errors occured: Framing 0, Parity 0, Overrun 1 (IF0:0), Break 0 ps. es ist kein usb Port! -CPU auslastung ist normal!
ich hab jetzt noch nicht alles durchgelesen, aber ich hatte ein ähnliches Problem. Mein DOS Programm nutzt die BIOS Funktionen und ist in Assembler geschrieben. Unter Win98 läuft es einwandfrei. Unter XP (anderer Rechner) wird entweder nichts auf dem Bildschirm ausgegeben (DOS Funktion) oder die Tastatur geht nicht. Dies ist abhängig, ob Fenster oder Vollbild. Ich habe dann im abgesicherten Modus gestartet und da funktionierte mein Programm. Es ist dann lediglich ärgerlich, daß der PC neu gestartet werden muß, wenn ich mein Programm ausführen will. Soll mal als Hinweis angesehen werden, vielleicht hilft es auch bei der COM Ausgabe. mfg
Ich habe wieder dran gearbeitet - 16550 implementiert und ein paar andere Verbesserungen. Die neue Datei: http://home.arcor.de/h-a-l-9000/test/dosbox_serial10_fifo.zip Man kann auch ein log anfertigen lassen, das nützlich für die Fehlersuche sein könnte: serial1 directserial realport:comx dbgall Die Datei erscheint dann im Unterverzeichnis 'capture'.
Hallo, ich habe die DosBox erst neu entdeckt, da ich bisher immer noch ein Notebook mit XP_Prof und Win98 als 2. BS hatte. Bei dem neuen (mit int. serieller Schnittstelle) nutze ich nun XP_Prof und Suse, muß aber noch auf IPC mit 386 mit DOS und SPS zugreifen können. Online Programmierung unter der DosBox läuft schon, aber um die Daten auf den IPC zu übertragen brauche ich noch den guten alten interlinker aus DOS. In Verbindung mit dem Norten Comander (der auf der DosBox auch prima läuft) ist diese Art der Datenübertragung sehr komfortabel. Gibt es die Möglichkeit den Interlnk in die DosBox zu integrieren? Bisher ist es mir noch nicht gelungen. Gruß Stefan
Evtl. reicht es, eine andere DOS-Version zu simulieren? ver set 6 22
Hallo *.* ich weis leider nicht wie ich die andere DOS-Version auswählen kann. Ich habe jetzt mein Problem gelöst indem ich VM-Ware installiert habe und darauf WIN98 als DOS starte. Braucht zwar wesetlich mehr Speicherplatz, funzt aber. Gruß Stefan
> ich weis leider nicht wie ich die andere DOS-Version auswählen kann.
Hab' ich doch geschrieben...
Hallo, möglicherweise habeich die Anweisung aneiner falschen Stelle in der confog. Datei eingetragen, denn bei dem Befehl ver zeigt mir die DosBox immernoch Versin 5.0 an. Kann ich bei device ***interlink auf ein lokales Laufwerk verweisen? Die lokalen Laufwerke werden doch eigentlich erst nach dem Start beim abarbeiten der autoexec eingebunden. Gruß Stefan
Das 'ver set 6 22' ist für die DOSBox-Kommandozeile selbst (oder wahlweise unter [autoexec] in der .conf). Kann aber sein, dass es trotzdem nicht funktioniert, der Emulator ist doch nur für Spiele ;). DOSBox kann übrigens auch ein MSDOS (Win95 geht in den neuesten Versionen auch mehr oder weniger) starten, dann ist es wahrscheinlicher, dass es funktioniert. Siehe IMGMOUNT- und BOOT-Kommandos, und BxImage. Entspricht dann dem Prinzip von VMware.
Hallo, "Das 'ver set 6 22' ist für die DOSBox-Kommandozeile selbst (oder wahlweise unter [autoexec] in der .conf)." hatte ich so eingegeben. Ergebnis: "Enviroment variable ver 6 22 not defined" Zum Tema Spiele, die SPS ist mein Speilzeug ;). Mit IMGMOUNT- , BOOT-Kommandos, und BxImage habe ich mich noch nicht befasst. Muss ich mich erst mal einlesen. Gruß Stefan
Angehängte Dateien:
-
dosbox_000.png
3,9 KB
Die Syntax ist anders als im echten DOS. Oder ist die Sache auf meiner Homepage schon wieder zu alt ;)
Hallo, habe mir nochmals die aktuelle Version geladen. Dos 6 22 geht nun. Muss nun morgen nochmals versuchen ob ich ein externes Laufwerk einbinden kann. Vorerst Vielen Dank für die Hilfe Stefan **************************************************************** DosBox ist für meine Anwendung wesentlich schneller als VMware ****************************************************************
hallo ich entschuldige mich mal vor ab und hoffe *.*(Gast) schaut noch mal rein. ich würde mich über einen kontakt freueen , da ich noch immer ein Problem mit einem FTDI dongle in der Dosbox habe näheres dazu habe ich hier beschrieben http://www.progforum.com/showthread.php?t=9616 Da ich den Fehler schon weitestgehend analysiert habe würde ich mich über Hilfe bei dessen Behebung freuen. Inzwischen gibt es Dosbox-0.74 aber sowohl diese als auch die Serialmod2 Versionen kommen nicht mit dem Punkt klar, das dieser Dongle mit FTDIChip keine 5bit Datenbreite unterstützt, welche ich auch gar nicht benötige, Die jedoch bei der Initialisierung der dosbox verwendet wird und welche einen Fehler verursacht. würde mann den defalt wert verändern aus 8 wäre das problem behoben. da genügte ein winziger patch, wenn ich wüste wo! Thanks Winne
Das ist eigentlich nur ein kosmetischer Fehler, wenn ich mich recht erinnere. Beim Schreiben der emulierten UART-Register wird zunächst auf 5 Bit eingestellt und direkt danach auf 8 Bit. Da die 5 Bit mit dem FTDI nicht gehen gibt es zunächst eine Fehlermeldung. FTDI hat ja einige zusätzliche Optionen bei den Anschlusseinstellungen. Hast Du probiert, die Wartezeit auf 1ms zu stellen bzw. verschiedene (niedrigere) Paketgrößen probiert?
Hallo, ich habe gerade div. Dos-Programme, die über die COMx mit verschiedenen Endgeräten kommunizieren, in Verbindung mit einem USB-Serial-Converter (Digitus mit FTDI-Chip) mit DOSBOX 0.74 unter WinXP und Win7 getestet, ... Es hat einwandfrei funktioniert (mit 8 Bit, 9Bit (Parity) und versch. Baudraten)! Dazu habe ich die die Einstellungen geändert: Timeout auf 4 ms, Puffergrösse (tx und rx) auf 64 Byte. Das Problem war mir nicht bewusst, da ich das Konsolenfenster ausgeschaltet hatte (-noconsole). Mit dem Konsolenfenster bekomme ich die gleiche Fehlermeldung. Also Fehlermeldung ignorieren, es geht trotzdem... Gruß Christian
Dir ist schojn klar daß das Ursprungsposting 6 Jahre alt ist, und die letzte Aktivität auf dem Thread 1 einhalb Jahre. Denkst du der TO wartet immer noch auf eine Lösung?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.