COM1-uitvoer van een DOS-programma doorsturen naar file

[Josefien]

Ik heb hier nog een relatief oud DOS-programma in gebruik. Het is bedoelt om teksten in te voeren voor een bepaald type bestemmingsaanduider van bussen. Na invoeren voert hij de gegevens uit in Intel-hex formaat wat klaar is om naar een EPROM te schrijven

Het "probleem" nu is echter dat het programma de gegevens alleen kan uitvoeren naar de seriële poort (COM1). Vroeger geen probleem, omdat het gebruikt werd met een EPROM-programmer op RS-232 die de gegevens zó konden opvangen in een buffer om later naar EPROM te schrijven.

Nu is zo'n programmer met RS-232 aansluiting en buffer echter niet voorhanden en moet ik een hele "omweg" maken om de gegevens alsnog op EPROM te krijgen met een Willem Programmer. Daarbij heb ik zelfs 2 PC's nodig:

1. Teksten invoeren op PC1.
2. PC2 verbinden aan de COM1 van PC1 waar het programma op draait, d.m.v. een nullmodem-kabel.
3. Op PC2 een terminal-programma starten.
4. Data verzenden vanaf PC1.
5. De op PC2 ontvangen data wegschrijven naar een HEX-file en inladen in de software van de Willem Programmer om te schrijven naar EPROM.


Dit is allemaal erg omslachtig en ik zoek eigenlijk een kortere weg


Ik heb zelf al eens geprobeerd het DOS-programma in DOSbox te draaien en de telnet-functie van DOSbox in te schakelen (deze wijst de uitvoer van COM1 naar een telnet-sessie). En dan een terminal-programma verbinden met de telnet-sessie. Echter, om een vage rede werkt dit niet betrouwbaar, regelmatig worden enkele karakters overgeslagen waardoor het uiteindelijke bestand niet bruikbaar is


Mijn vraag is: is er een mogelijkheid om op één PC de uitvoer van COM1 door te sturen naar een bestand? Besturingssysteem maakt mij niet uit, als het proces maar op één PC kan. Het is zelfs geen probleem als het op DOS moet Echter het liefst zonder gebruikmaken van één of meerdere virtuele machines met volledig OS.


De DOS-software anders instellen is geen optie. Het is een behoorlijk primitief programma, de data naar een file uitsturen behoort niet tot de mogelijkheden. Ook een andere seriële poort dan COM1 gebruiken is geen mogelijkheid, daar is simpelweg geen instelmogelijkheid voor beschikbaar. En wachten op een nieuwe versie is al helemaal geen optie: het type bestemmingsaanduiders waar dit programma voor bedoeld is wordt al jaren niet meer gebruikt. De mijne is een object van mijn verzameling

[gekkie]

je zou kunnen kijken naar com1 naar file redirect in dos a la: "COM1 > output.file"
( http://www.robvanderwoude.com/redirection.php )

maar misschien dat een sysinternals tooltje ook wil werken en wat makkelijker is:
http://technet.microsoft....ysinternals/bb896644.aspx

[lordsnow]

Waarom niet de tekst invoeren op PC2, waar de Willem Programmer op aangesloten is?

[soulrider]

werken met virtuele compoort op pc1 of ev. een usb-naar-com-poort-adaptertje gebruiken?
dan kan je die laatste aansluiten op enerzijds de usb-poort en anderzijds de com-poort van telkens PC1.
en kan je alles op 1 computer draaien ?
maw: dat oude programma schrijft bv naar com1, je draait terminalserver op com2 die je krijgt mbv zo'n sub-com-adapter, en je sluit com1 en com2 via een kabel aan elkaar (zoals je nu doet tussen je 2 pc's)

lordsnow schreef op zaterdag 11 oktober 2014 @ 01:04:
Waarom niet de tekst invoeren op PC2, waar de Willem Programmer op aangesloten is?

omdat dat programma de output steeds naar com1 stuurt en dus niet naar die willem programmer kan sturen omdat die niet aan een com-poort hangt?
effe de probleem stelling opnieuw doorlezen...

mogelijkheid is eventueel wel dat er toch een nieuwe versie van dat programma bestaat waarbij de uitvoerpoort toch geconfigureerd kan worden of waarbij er toch een bestand kan aangemaakt worden van de output.

[ Voor 40% gewijzigd door soulrider op 11-10-2014 01:22 ]

[Lustucru]

Met com0com maak je twee virtuele com poorten met een even virutele nul-modemkabel ertussen
Vervolgens met een dos-commando de input naar file laten schrijven.

[Jorgen]

Josefien schreef op zaterdag 11 oktober 2014 @ 00:25:
Ik heb hier nog een relatief oud DOS-programma in gebruik. Het is bedoelt om teksten in te voeren voor een bepaald type bestemmingsaanduider van bussen.

[...]

En wachten op een nieuwe versie is al helemaal geen optie: het type bestemmingsaanduiders waar dit programma voor bedoeld is wordt al jaren niet meer gebruikt. De mijne is een object van mijn verzameling

Mag ik vragen wat jij er dan mee doet? Heb jij thuis een oude bus staan? Of de lichtkrant boven de voorruit in de woonkamer hangen? Ben hier eigenlijk wel nieuwsgierig naar. Heb het net via de link in je profiel gelezen. Grappig.

[ Voor 4% gewijzigd door Jorgen op 11-10-2014 09:29 ]

[Josefien]

gekkie schreef op zaterdag 11 oktober 2014 @ 00:49:
je zou kunnen kijken naar com1 naar file redirect in dos a la: "COM1 > output.file"
( http://www.robvanderwoude.com/redirection.php )

maar misschien dat een sysinternals tooltje ook wil werken en wat makkelijker is:
http://technet.microsoft....ysinternals/bb896644.aspx

Redirection krijg ik niet werkend onder DOS. Het commando "COM1 > output.hex" is niet geldig.

Iets als "echo file.hex > com1" werkt wel, maar dat is om data uit de com1 te sturen...

Het Sysinternals-progje moet ik nog op een andere PC gaan uitproberen. Op Windows 7 werkt het i.i.g. niet, het progje ziet dan geen COM-poorten.

soulrider schreef op zaterdag 11 oktober 2014 @ 01:18:
werken met virtuele compoort op pc1 of ev. een usb-naar-com-poort-adaptertje gebruiken?
dan kan je die laatste aansluiten op enerzijds de usb-poort en anderzijds de com-poort van telkens PC1.
en kan je alles op 1 computer draaien ?
maw: dat oude programma schrijft bv naar com1, je draait terminalserver op com2 die je krijgt mbv zo'n sub-com-adapter, en je sluit com1 en com2 via een kabel aan elkaar (zoals je nu doet tussen je 2 pc's)

mogelijkheid is eventueel wel dat er toch een nieuwe versie van dat programma bestaat waarbij de uitvoerpoort toch geconfigureerd kan worden of waarbij er toch een bestand kan aangemaakt worden van de output.

Het fysiek verbinden van twee poorten is wellicht wel een goed idee Ik ga dat eens een keer proberen op een oudere PC met 2 COM-poorten. Een USB<=>RS232 kabel is momenteel niet voorhanden

Een nieuwere versie van het programma is niet beschikbaar. De huidige versie heb ik gekregen van degene die het destijds distribueerde. Dat bedrijf bestaat inmiddels al een tijdje niet meer...

Lustucru schreef op zaterdag 11 oktober 2014 @ 01:39:
Met com0com maak je twee virtuele com poorten met een even virutele nul-modemkabel ertussen
Vervolgens met een dos-commando de input naar file laten schrijven.

Net geprobeerd, maar de data komt corrupt aan. Er worden willekeurige tekens gedropt

[Raven]

Josefien schreef op zaterdag 11 oktober 2014 @ 18:44:
[...]
Redirection krijg ik niet werkend onder DOS. Het commando "COM1 > output.hex" is niet geldig.

Iets als "echo file.hex > com1" werkt wel, maar dat is om data uit de com1 te sturen...

Het Sysinternals-progje moet ik nog op een andere PC gaan uitproberen. Op Windows 7 werkt het i.i.g. niet, het progje ziet dan geen COM-poorten.

Ook niet als je 'm uitvoert als admin?

[Lustucru]

Josefien schreef op zaterdag 11 oktober 2014 @ 18:44:
[...]
Net geprobeerd, maar de data komt corrupt aan. Er worden willekeurige tekens gedropt

Bijzonder... Lijkt dus op het probleem wat je hebt met je telnet - dosbox sessies. Hetzelfde effect als je bv hyperterminal de ontvangende com-poort laat uitlezen? Struiktelt hij wellicht over stuurtekens?

[ Voor 11% gewijzigd door Lustucru op 11-10-2014 19:33 ]

[Josefien]

Nog niet verder gekomen. Ik heb een PC met 2 COM-poorten (een oude Pentium II 333MHz) staan, maar die bleken op de één of andere manier niet te kunnen ontvangen. Het gebruikte terminal-programma crashed op de één of andere manier als er data binnenkomt. Zowel als ik COM1+COM2 op dezelfde PC verbind alsook als ik met een andere PC verzend En zowel met Windows 98 als Windows XP.

Raven schreef op zaterdag 11 oktober 2014 @ 19:02:
[...]

Ook niet als je 'm uitvoert als admin?

Ja, ook dan ziet hij geen poorten...

Lustucru schreef op zaterdag 11 oktober 2014 @ 19:32:
[...]

Bijzonder... Lijkt dus op het probleem wat je hebt met je telnet - dosbox sessies. Hetzelfde effect als je bv hyperterminal de ontvangende com-poort laat uitlezen? Struiktelt hij wellicht over stuurtekens?

Ja, het effect is hetzelfde. Er worden voor zover ik weet, geen stuurtekens meegezonden

[gekkie]

al eens gekeken in je hexfile of er af te leiden wat er dan precies anders is als je het via je oude manier doet .. en via een nieuwe manier probeert ?

[synoniem]

Wat voor een soort bewerking voert dat programmaatje uit? Ik kan me zo voorstellen dat als het niet al te ingewikkeld is je sneller een nieuw programma kan schrijven dan het hardwarematig uitvoeren of virtualiseren van het oude programma.

[Josefien]

gekkie schreef op zondag 12 oktober 2014 @ 14:53:
al eens gekeken in je hexfile of er af te leiden wat er dan precies anders is als je het via je oude manier doet .. en via een nieuwe manier probeert ?

Er veranderd vrijwel niets, behalve dat er een aantal tekens zijn weggevallen.

synoniem schreef op zondag 12 oktober 2014 @ 15:05:
Wat voor een soort bewerking voert dat programmaatje uit? Ik kan me zo voorstellen dat als het niet al te ingewikkeld is je sneller een nieuw programma kan schrijven dan het hardwarematig uitvoeren of virtualiseren van het oude programma.

Het programma laat je teksten invoeren welke in een aantal ascii-files worden opgeslagen. Bij uitvoer naar eprom-formaat wordt dat omgezet naar een lange reeks en worden opmaaktekens toegevoegd wat voor de bestemmingsaanduider begrijpbaar is en dan als zijnde hex-formaat de com1 uitgestuurd.

Ik kan zelf niet programmeren, dus een nieuw programma schrijven behoort niet tot de mogelijkheden.

[Lustucru]

Lijkt er toch op dat er e.e.a. mis gaat met de handshake zodra je applicatie gaat praten met een virtuele poort. Je kunt wat experimenteren met de verschillende RS232 instellingen (handshake, bitrate). Ik heb het niet meer scherp op mijn netvlies, maar het staat me bij dat als er niet gebruikt wordt gemaakt van CTS/CTR lijnen en de software denkt wel dat die er zijn, dat dan idd bytes gedropt kunnen worden, met name bytes die kunnen worden geinterpreteerd als Xon/Xoff bytes.

Anyway: zoek eens op serial port sniffer. Genoeg tooltjes die je rs232 poorten kunnen monitoren en naar file schrijven.

[Josefien]

Ik zal de komende week eens verder kijken :-)

De DOS-software gebruikt voor zover ik weet geen handshaking. Instellingen voor de poort is 9600 baud, 7 databits, even parity, 1 stopbit en geen handshaking.

Ofwel de software stuurt de data "onvoorwaardelijk". Zelfs als je niks zou aansluiten op de com1, wordt de data gewoon uitgestuurd.

[Witte]

In VMWare kan je de COM-poort koppelen aan een file op de host:

[ Voor 37% gewijzigd door Witte op 13-10-2014 10:30 ]

[sam.vimes]

Witte schreef op maandag 13 oktober 2014 @ 10:26:
In VMWare kan je de COM-poort koppelen aan een file op de host:
[afbeelding]

In virtualbox kan het ook. Met een linuxbox als host kun je zelfs com1 aan een pipe koppelen waardoor je bidirectionele communicatie hebt.

[Josefien]

VMware is niet voor handen.

VirtualBox met een Linux-host heb ik wel zo-net geprobeerd, maar werkt niet. Installeren van MS-DOS 6.22 ging nog prima, maar zodra ik het DOS-programma probeerde te starten, crashte VirtualBox:


Los daarvan:
Sowieso is het werken met VirtualBox niet prettig. Er zitten geen fatsoenlijke mogelijkheden in om vanuit de host files over te zetten naar de guest. Het overzetten v/h DOS-programma via floppy-images (de fysieke LS-120 floppy koppelen aan de guest kan blijkbaar niet) was al een heel gedoe. Onder Ubuntu kan je wel met dd een leeg image aanmaken, maar moet je weer een root-terminal openen om te formatteren en loopback-mounten. Dan heb je weer met schrijfrechten te maken en moet je blijkbaar umask=0000 expliciet opgeven bij het mounten.

Ik had trouwens ook geprobeerd met "dd if=/dev/sdb of=image.img" direct de diskette waar het programma op staat over te zetten naar een image-file voor VirtualBox. Maar op de diskette zit zo'n ongebruikte bad-sector die al gemarkeerd is in de FAT. Daar kan dd blijkbaar niet overheen kijken en loopt vast. Ach ja...

[ Voor 3% gewijzigd door Josefien op 03-07-2016 17:59 ]

[synoniem]

Josefien schreef op zondag 12 oktober 2014 @ 23:45:

[...]
Het programma laat je teksten invoeren welke in een aantal ascii-files worden opgeslagen. Bij uitvoer naar eprom-formaat wordt dat omgezet naar een lange reeks en worden opmaaktekens toegevoegd wat voor de bestemmingsaanduider begrijpbaar is en dan als zijnde hex-formaat de com1 uitgestuurd.

Ik kan zelf niet programmeren, dus een nieuw programma schrijven behoort niet tot de mogelijkheden.

Als je weet welke opmaaktekens waar toegevoegd moeten worden, wil ik wel proberen een programmaatje voor je te maken dat het hex-bestand aanmaakt.

[akimosan]

VMWare player is ook een leuke hypervisor voor op de desktop. Gratis voor persoonlijk gebruik.

[Josefien]

synoniem schreef op donderdag 16 oktober 2014 @ 19:56:
[...]

Als je weet welke opmaaktekens waar toegevoegd moeten worden, wil ik wel proberen een programmaatje voor je te maken dat het hex-bestand aanmaakt.

Ik vrees dat het lastig wordt

Ik heb eens met een hex-editor gekeken in het uiteindelijke bestand, maar ik kon niet volledig de logica ontdekken van de opmaak ervan Vooral de startpositie van de teksten-lijst blijkt nogal om (voor mij) onbekende reden te verschillen. Als de startpositie niet juist is, wordt het blijkbaar niet gelezen door de firmware in de aanduider

Verder bestaan de opmaaktekens alleen uit aanwijzingen voor 1 of 2-regelig, lijncijfer en wisselteksten en diverse scheidingstekens.

Het lettertype wordt automatisch bepaald door de firmware v/d aanduider afhankelijk v/d tekstlengte. In de DOS-software zit dus ook geprogrammeerd wat voor lettertypes er in de firmware zitten/hoe breed ze zijn, om de gebruiker te waarschuwen dat het max. aantal karakters is bereikt. Als de aangeboden tekst namelijk langer zou zijn dan de aanduider, gaat deze op zwart.

akimosan schreef op vrijdag 17 oktober 2014 @ 19:33:
VMWare player is ook een leuke hypervisor voor op de desktop. Gratis voor persoonlijk gebruik.

Ik ga morgen eens kijken. Ik dacht dat VMware Player alleen bestaande VM's kon openen, tegenwoordig niet meer zo blijkbaar

[johnkeates]

Je kan Xen gebruiken of KVM. Voor DOS heb je ook niet perse een echte hypervisor nodig, een emulator gaat ook wel werken gezien het niet zo veel resources vreet. Kijk daarom ook even naar QEMU. Alle drie kunnen virtuele COM poorten maken die door DOS prima gebruikt kunnen worden en op de host als file gebackt kunnen worden. Allemaal gratis. (en gezien je window manager naar Ubuntu ruikt: alles is makkelijk via apt te installeren. Ook via je software GUI's. QEMU heeft zelfs nette GUI's tegenwoordig!)

[ Voor 19% gewijzigd door johnkeates op 20-10-2014 02:06 ]

[Josefien]

Ik heb vanochtend even VMware Player geprobeerd... werkt ook niet... VMware crasht als ik het DOS-programma wil starten:


QEMU heb ik nog niet geprobeerd.

[ Voor 20% gewijzigd door Josefien op 03-07-2016 17:59 ]

[The Eagle]

Waarom gebruik je niet gewoon een DOS bootdisk waarvan je native opstart?
Hoef je al die hypervisor ellende ook niet te hebben. En kan tegenwoordig ook vanaf USB vziw, dus dan heb je een volledige DOS omgeving en je progsel op 1 stickje

Zag btw een Mac OS screenshot, maar aangezien dat tegenwoordig x86 hardware is zou ook dat gewoon moeten werken

[Killah_Priest]

The Eagle schreef op zondag 26 oktober 2014 @ 12:44:
Waarom gebruik je niet gewoon een DOS bootdisk waarvan je native opstart?
Hoef je al die hypervisor ellende ook niet te hebben. En kan tegenwoordig ook vanaf USB vziw, dus dan heb je een volledige DOS omgeving en je progsel op 1 stickje

Zag btw een Mac OS screenshot, maar aangezien dat tegenwoordig x86 hardware is zou ook dat gewoon moeten werken

Zie de OP, daar staat waarom dit niet echt lekker werkt (2e pc nodig om de data af te vangen)

[johnkeates]

The Eagle schreef op zondag 26 oktober 2014 @ 12:44:
Zag btw een Mac OS screenshot

Waar zag jij een Mac OS screenshot? Behalve Linux (Ubuntu) en Windows heb ik nog niks anders langs zien komen...

Josefien schreef op zondag 26 oktober 2014 @ 12:24:
Ik heb vanochtend even VMware Player geprobeerd... werkt ook niet... VMware crasht als ik het DOS-programma wil starten:

VMWare heeft een crappy hypervisor (ja, dat is gewoon zo, het werkt alleen goed met current Windows en Linux guests). Kan diverse DOS CPU mode switches achter elkaar niet aan, en heeft heel veel moeite met het emuleren van bepaalde geheugenlocaties.

Kijk of het met QEMU in volledige emulatiemodus werkt, die kan als het goed is ook prima met DOS overweg als het van protected mode naar real mode wil switchen en weer terug (en weer een paar keer heen en weer), en kan ook genoeg adresruimtes emuleren op zo-goed-als-native om ook de meeste rare programma's die x86 bugs gebruiken om bepaalde taken te verrichten te kunnen ondersteunen.

Als je wil dat ik het even in een paar VM's en hypervisors probeer (ik heb een divers setje), stuur dan even je binary door of post een link.

[ Voor 68% gewijzigd door johnkeates op 27-10-2014 00:15 ]

[Fish]

waarom geen com port logger zoeken

e.g. http://sourceforge.net/projects/rs232portlogger/
http://sourceforge.net/projects/rs232portlogger/

[noMSforme]

Hier is redelijk wat info te vinden:
http://www.downtowndougbr...mmer-on-windows-7-64-bit/

Kun je wat meer info geven:
Welke versie gebruik je?
Wat is je standaard OS?
etc.

[johnkeates]

fish schreef op maandag 27 oktober 2014 @ 00:23:
waarom geen com port logger zoeken

e.g. http://sourceforge.net/projects/rs232portlogger/
http://sourceforge.net/projects/rs232portlogger/

Om dat dat niet werkt, dat is al getest.

noMSforme schreef op maandag 27 oktober 2014 @ 00:33:
Hier is redelijk wat info te vinden:
http://www.downtowndougbr...mmer-on-windows-7-64-bit/

Kun je wat meer info geven:
Welke versie gebruik je?
Wat is je standaard OS?
etc.

Heb je dit draadje wel doorgelezen? Staat allemaal al meerdere malen in diverse posts.
Daarbij is het probleem ook niet met de programmer, maar met het programma dat de hexfiles maakt onder DOS.

[ Voor 45% gewijzigd door johnkeates op 27-10-2014 00:40 ]

[Fish]

doe jij eens even wat vriendelijker ...

een excuus zou je beter passen dan een ninja edit

[ Voor 40% gewijzigd door Fish op 27-10-2014 00:50 ]

[Raven]

johnkeates schreef op maandag 27 oktober 2014 @ 00:11:
VMWare heeft een crappy hypervisor (ja, dat is gewoon zo, het werkt alleen goed met current Windows en Linux guests). Kan diverse DOS CPU mode switches achter elkaar niet aan, en heeft heel veel moeite met het emuleren van bepaalde geheugenlocaties.

offtopic:
Waarom kan ik dan zonder problemen W3.11 draaien in een door VMware Player gestartte VM?

Misschien een te recente hardware versie ingesteld bij het aanmaken van de VM?

[ Voor 7% gewijzigd door Raven op 27-10-2014 09:57 ]