How do you know there isn't just electrical cross-talk between your parallel port device and your sound card or speakers? This seems to be much more likely.

I would suggest booting your computer into DOS and testing your program there. If you are using a USB-to-parallel adapter that doesn't work in DOS, there's probably no chance of getting it to work with DOSBox either, as these devices are severely limited in their capabilities. (I assume you're using a build of DOSBox that includes parallel port passthrough.) SystemRescueCD provides a quick and easy means of booting into FreeDOS from a USB drive; you can inject any programs you need into the included FreeDOS disk image using Virtual Floppy Drive or DiskExplorer.

And yes, this should be in the DOSBox forum.

Does Dosbox enable Covox emulation by default? You might want to disable that.

The USB-LPT device is developed by me and my classmates, so we know it's working 😀. Currently, it's only about getting the data out of the dosbox. I have no LPT-port attached, so i doubt intereference is the issue here. The dosbox is playing audio signals (verified with several computers) which are sent from the program to the dosbox (Stepmotorcontrol-Data for LM298s). We believe that the dosbox thinks, those were audio data , due to the incorrect port adressing of the programm (it's not sending to standard adresses like 0x3BC, 0x378 or 0x278). When the dosbox recognizes LPT data (e.g. on port 0x378) it doesn't sent those to the speaker, that's why we blame the cnc-programm for improper port handling.
In plus, this happens only with LPT2 set as the output port in the program (actually a port the CNC-Programm believes to bei LPT2, we believe to be the dosbox-internal sound port).
Covox disable did nothing, but to turn the speakers of.

How do i move the post? (i suggest to dosbox-development).

niklas1812 wrote:

The USB-LPT device is developed by me and my classmates, so we know it's working 😀.

This is confusing. If I'm not mistaken, all DOSBox does (or rather the specialized builds of DOSBox) is address a parallel port through PortTalk (or something similar like InpOut32). If it does not behave like an actual parallel port according to Windows, there is no point in expecting DOSBox to address it like an actual parallel port.

Are you using PortTalk and a build of DOSBox that includes parallel port passthrough? Because otherwise DOSBox doesn't emulate a parallel port at all.

Well I am propably confusing you (I'm not a native speaker, neither writer 😀)

Chain is as follows:

Normal:

Test programm decides to sent a byte (let's say 01110111) to LPT1
-> it sents 0x77 (byte above) to the port 0x378
Dosbox catches that and internally forwards byte 0x77 to an instance of device_lpt1 (C++ class)
(the instance is actually newdev3 [created at startup])
We have reprogrammed this device-class to sent this data to a test file (test.dat)
-> That Works! (test.dat contains small "w" which is the ASCII-Character with the HEX-Code 77)

Faulty:

CNC-Programm decides to sent a byte (let's say 01110111) to the set LPT-Port
-> it sents 0x77 (byte above) to the port 0xXXX (we don't know port number)
Dosbox catches that and detects port number NOT as LPT-Port but allegedly as Sound-Device
Dosbox forwards that data to windows-host, which sends it to Soundcard
-> That's not what is supposed to do 🙁

sounds like the disney/covox port you are sending stuff to.
disable it in the options file.. but I don't recall from my head if lpt will pick it up then.
*moved to dosbox general*

Sadly it then doesn't forward (at which port the internal LPT-Device would have to be configured then?) after disabling COVOX/DISNEY in config.
Is there any premade Code, which lists all port Communication between the DOSbox and the running program (With sent data and port). If not, where would such a thing be integrated in the code?
Thanks for moving 😀

I may have misunderstood BIOS_ADDRESS_LPT1- is it storing the Port of the lpt on the host, or the port at which programs in the dosbox ar accessing the emulated lpt device?

the latter.
check disney.cpp for the port numbers

That did the trick 😀
Set some stopping points for debugging in disney_write and the disney.data of the current instance contains my data.
I think I just go from here with remodeling disney/covox stuff.
Thank you very much 😀

Can anyone close this thread or mark it as solved?