#260 Anyone else's opinion on LPT support?

[L.L. Athey]

The changes to the source tree submitted last night fixed a printing problem I had with 1 of 2 programs. Yet, one program, still insists that the printer is offline. Do I point the finger at a DMA related issue? I don't know, so far, I can't see any way of monitoring what is going on communications-wise with the parallel ports.

I do know that no matter what I do in dosemu.conf, LPT1 still exists, even if I add $_lpt1 = "" in the conf file. Granted, all of its bits/pins are set high, thus rendering it useless. But, one would assume that if you put $_lpt1 = "" and $_lpt3 = "" in there, then both LPT1 and LPT3 would appear unavailable when you run a system profiler or a parallel port debugger in dosemu.

For the record, I get the same problem when I run "mode LPT1:=NUL" before running the program in question. Same result, the printer is offline. Other than a DMA issue, I'm at a loss for ideas. What is it that makes a parallel port so impossible to emulate under VMs? VirtualBox can't do it, VMware can't, DOSbox can't...There is obviously something that I'm missing here, but the obvious is escaping me.

Anyinput from anybody?

[Stas Sergeev]

Do I point the finger at a DMA related issue?
No because dosemu only implements SPP mode.
Maybe the APP misdetects it as ECP.
Another thing to think about is an lpt IRQs which
dosemu does not implement.

I can't see any way of monitoring what is going on communications-wise with the parallel ports.
I added the logging for you, update from git and enjoy.
dosemu -D9+p

I do know that no matter what I do in dosemu.conf, LPT1 still exists, even if I add $_lpt1 = ""
That's likely because of this:

---

15-14 number of parallel devices
00 or 11 sometimes used to indicate four LPT ports

---

So basically there is no way to specify 0.

What is it that makes a parallel port so impossible to emulate under VMs?
Maybe the simple fact that people didn't have the progs you
are testing, so they tested what they had and that was it?
Just try it yourself, and you'll see what makes it so impossible. :)
Certainly the SPP mode coupled to the Centronics printer is not
a rocket science to emulate, and dosemu is not aimed to something
above this.

[L.L. Athey]

I'll take your word for it, I certainly wouldn't want to try and figure out how to simulate a piece of hardware that isn't really there. I had enough fun with that back in my BBS days creating a spooling system to create a fake modem connection between my own BBS program and its proprietary graphical terminal program.

I guess I will have to drop back and punt on this. Comparing the problematic DOS program to a known working DOS program, such as edit.exe - they both do the following in the log.

LPT: initializing printer <<NODEV>>
LPT: initializing printer <<NODEV>>
LPT: initializing printer <<NODEV>>
~
LPT0: Reading control byte 0xc
LPT0: Writing control byte 0x8
LPT0: Writing control byte 0xc
LPT0: Reading status byte 0xdc

And that's as far as the log gets with the problematic DOS program, but the edit.exe program will go as far as causing this in the logs when it successfully prints.

LPT0: Writing data byte 0x20
LPT0: Reading control byte 0xc
LPT0: Writing control byte 0xd
LPT0: Writing control byte 0xc
LPT: doing printer command ../usr/bin/lpr -l -P lp..
LPT: opened printer 0 to <<NODEV>>, file 0xa1821d8

So I guess I'm stuck limping along with Windows XP and DOS2USB for that program. That's life, but at least I'm able to break 90% of my dependency on that lonely XP clunker.

[Stas Sergeev]

I'll take your word for it
My word was that it is not difficult.

fun with that back in my BBS days creating a spooling system to create a
fake modem connection between my own BBS program and its proprietary
graphical terminal program.
People were doing this with dosemu for long:
http://www.synchro.net/docs/linux-dosemu.html
Running the remote BBS software locally with
dosemu-simulated com port is what they do.
But I really think they had to implement it as
a fossil extension and not as a dosemu extension.

LPT0: Writing control byte 0x8
LPT0: Writing control byte 0xc
LPT0: Reading status byte 0xdc
So it is trying to initialize the printer and reads
back the status, but our "printer" does not need
to be initialized. Maybe it expects it to go off-line
for a short period of time, or assert a "Busy" line -
just try some experimenting. There is also a tool
dosdebug which can help you.

[L.L. Athey]

I guess I may be showing my ignorance here...Is there some dosemu documentation that explains how to assert a "Busy" line on an active virtual LPT port and where to locate/obtain this dosdebug program?

[Stas Sergeev]

Is there some dosemu
documentation that explains how to assert a "Busy" line
This "documentation" is written in C and is in the file lpt.c.
Get used to it. :)

where to locate/obtain this dosdebug program?
Type "dosdebug" in your console.