www.mikrocontroller.net

Forum: PC-Programmierung DOS-Programm mit ser. Schnittstelle unter Win XP


Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, mach ich mal...

Ralf

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. auch mit dem Dosbox-Emulator, der kann auf serielle Schnittstellen
zugreifen.

http://sourceforge.net/projects/dosbox

Autor: DL4MCV (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was spricht dagegen, von Diskette zu booten? Da passt wahrscheinlich
neben den Startdateien auch noch Dein Pascal-Programm drauf.

Autor: Der Elektronikfreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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!

Autor: Andreas Häusler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef Droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier den Dosbox Emulator...

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c) im Emulator laufen lassen

Autor: Josef Droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Josef Droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: josef Droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef Droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

scheint wirklich wunderbar zu funktionieren!!!!


Danke für den Tip

Autor: josef droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles super, wie bekomme lasse ich denn bei der DosBox das Satus Windows
verschwinden?

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dosbox.exe -noconsole

Autor: Martin Steininger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
DLLs im Anhang.

@Ralf:
Nicht zu viele Hoffnungen machen, bei zeitkritischen Anwendungen kann
der Emulator durchaus versagen.

Autor: josef droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muss ich wohl nochmal ran... ist mir schon mal aufgefallen, habe es
dann aber aus den Augen verloren.

Autor: josef droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: josef droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich noch vergessen. der Auzug aus der CONF Datei:

serial1=directserial realport:com1 irq4
serial2=directserial realport:com2 irq3


Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: josef droll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.



Autor: *.* (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kHz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@*.*

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...

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo Meinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tilo Meinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).


Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwartet denn "EEPROM" die zu programmierenden Daten via stdin? Das ist 
bei DOS-Programmen extrem ungewöhnlich.

Autor: Tilo Meinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

Autor: Tilo Meinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube es ja, nur ist das halt wirklich selten. Bei der unixoiden 
Herkunft des Tools ist es natürlich nicht verwunderlich.

Probiere mal
type IOCP-E_mem_SPD.x | EEPROM WRITE -I COM1 I2C_ROM_5
aus, vielleicht geht das ja auch nicht ...

Trotzdem viel Erfolg!

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
| 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=deta...

> 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.

Autor: Tilo Meinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Die Dosbox muß aber verändert werden, einfach nur Porttalk laden 
funktioniert nicht.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... 2. Versuch ...

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die startbps: und parity: werden in den neuen Versionen gar nicht mehr 
ausgewertet. Die DOS-Software setzt diese normalerweise selbst.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.




Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen gibt es die DOSBox 0.70. Wenn das Problem da auch auftritt 
muss ich wohl nochmal ran...

Autor: Christian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Leider läuft die Dosbox 0.70 nicht, sondern bricht mit der
Fehlermeldung siehe Anhang ab.

Autor: Christian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei noch die erzeugte Fehlerdatei e01_appcompat.txt.
Ich hoffe das sagt was aus.
Gruß Christian

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Riecht nach schlechtem DirectX oder Grafiktreiber...

Versuch mal die neueren Builds, die schalten in den Schneckengang 
anstatt abzustürzen.
http://builds.tharos-online.de/

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann es ;) ist aber nur ein Experiment und nicht in den offiziellen 
Versionen enthalten.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Der Hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Der Hubert:

Die Baudraten usw. werden von den meisten Anwendungsprogrammen selbst 
gesetzt.

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_serial...

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'.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. reicht es, eine andere DOS-Version zu simulieren?

ver set 6 22

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich weis leider nicht wie ich die andere DOS-Version auswählen kann.

Hab' ich doch geschrieben...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: *.* (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Syntax ist anders als im echten DOS.
Oder ist die Sache auf meiner Homepage schon wieder zu alt ;)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
****************************************************************

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Schmitt (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Beitrag #2751562 wurde von einem Moderator gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.