Have you tried printing in a DOS application?

I don't think the DOSBox command prompt supports piping (i.e. redirecting using ">"); you might need 4DOS for that.

EDIT: Or maybe it does. Regadless, the first question is relevant. (Also, you might need a space after ">".)

Also, what lines do you currently have in your DOSBox configuration file?

Hello Jorpho, I can do a "dir >prn" from the root directory on DosBox MB6 and that actually prints. It does not seem to matter whether I use the Linux name for the printer or the network name as follows:
DosBox-mb6.conf using the Linux name:
parallel1=reallpt realport:HP-LaserJet-m2727-MFP
or:
DosBox-mb6.conf using the network name:
parallel1=reallpt realport:HPLaserJ
I have also tried placing the IP address of the printer which is 192.168.1.2 before the name, but that does not allow it to print.
I have tried printing from dBase 5 for Dos, but that states that the printer port is not correctly configured; so I cannot print there.
I am beginning to think there is a problem with my compile of DosBox MB6.
Any ideas?

potionmaster wrote:

even listing a directory in DosBox as "dir *.* >prn" or "dir *.* >lpt1" does not work.

potionmaster wrote:

I can do a "dir >prn" from the root directory on DosBox MB6 and that actually prints.

I'm confused.

In this thread a line along the lines of "parallel1=file dev:lpt1" is suggested. (I guess you would use the Linux equivalent for "dev:lpt1".)

Hello Jorpo, we are both confused.
I have DosBox SVN Daum installed in a Windows XP machine and it prints perfectly with the commands you suggest from any mounted drive, directory and sub-directory.
But I want this going for Linux to get some legacy Dos programs such as dBase 5 up and running.
As it stands, it appears that I can print using a whole range of commands in dosbox-mb6.conf; as long as these are recognizable by Ubuntu.
The only problem is I can only print from the root directory on the C:\ drive, not from anywhere else and dBase states that there is an "incorrect printer port setting" and will not print at all; nor will any other Dos programs I have.
There has to be something fundamentally wrong with the version of dosbox mb6 I have compiled.

potionmaster wrote:

The only problem is I can only print from the root directory on the C:\ drive, not from anywhere else

So you're saying "dir > prn" works from C:\, but not from a subdirectory? What about "dir > c:\prn" ?

Hello Jorpho, yes, that works from any directory.
But that still does not solve my problem of printing from a program.
dBase 5 still does not recognize the printer port; and that is what I need to get going.
I have in the meantime actually recompiled dossbox mb6 with the original files downloaded from http://source.dosbox.com/mb6/dosbox-mb6.tar.gz and without the updated files from the archive parport_2nd_attempt.tar.gz which I downloaded as recommended from:
Re: dosbox megabuild setup.cpp error
This did not seem to make a hoot of difference to the end product.
Clearly one should be able to print from any directory or sub-directory.
So there has to be something wrong with the code of dosbox mb6.

Jorpho wrote:

So you're saying "dir > prn" works from C:\, but not from a subdirectory? What about "dir > c:\prn" ?

potionmaster wrote:

Hello Jorpho, yes, that works from any directory.

There were two questions there. What works from any directory? "dir > prn", or "dir > c:\prn" ?

Sorry about that.
"Dir > C:\prn" works from any directory and drive,"dir > prn" only works from the root directory of the C:\ drive (no other mounted drive or subdirectory).
Equally, if I try to print from a Dos application such as dBase 5, it comes up with an "invalid printer port" error.

potionmaster wrote:

Sorry about that.
"Dir > C:\prn" works from any directory and drive,"dir > prn" only works from the root directory of the C:\ drive (no other mounted drive or subdirectory).

I see. I agree, that definitely sounds like bug. I'm not sure if it's related to your inability to print from dBase 5, though.

Have you tried the virtual printer, just for debugging purposes?

You might want to put "Linux" in your subject line to be clear.

Hello Jorpho, set "parallel1=printer" in dosbox-mb6.conf.
Now dBase 5 no longer comes up with a printer error when I "set print on", but when I try to print some data (by giving the command: dir *.*) it locks up, I presume because the printer data has nowhere to go.

Does that mean you get a "page.bmp" in your DOSBox directory when you print in dBase 5, as in Virtual printer ?

Also, you will have to edit the subject line of your first post for it to display in the forum.

I think it should generate a png file. At any rate, there is no BMP, nor a PNG file. So printing seems to not take place.

Did a recompile of the source code, and this time added the line:
#include <stddef.h>
to the file: "dos_inc.h" at line 30 as instructed.
but not to the files: cpu.cpp, dos.cpp and ems.cpp.
It now generates a print file as expected if I set the lines in dosbox-SVN.conf as follows:
parallel1=file append:dosbox00.prn
parallel2=file append:dosbox00.prt
I have written a shell file for Linux that scans for these files and prints these to the respective network printer (network printer 1 gets sent the ".prn" file and printer 2 the ".prt" file).
It's all a bit of a fiddle, but it works.
There is only one issue left, and that is that dBase 5 seems to save its files to dosbox memory and the file does not get released until you exit dosbox; a bit of a pain but not fatal.
But if there is a solution for this, please let me know.

I think it's in the readme. Try the "rescan" command, or CTRL-F4.

Glad you got it working, anyway.

Hello Jorpho, thanks for that.
Have not had any luck to get Dosbox mb6 to release the ".prn" file, it remains at 0 bytes until I shut down Dosbox.
I think the problem is not that the CTRL-F4 command does not work but that dBase 5 captures the command and Dosbox never gets it.
I remember that the same problem occurred in stock-standard Dosbox 0.74; so it is not a unique Dosbox mb6 problem.
I would love a timer in Dosbox that automatically releases stuff in memory, but I won't hold my breath and I guess until then I am bound to exit the dBase program to print the data.

Here is a possible fix for the dBase printing problem that I found online. If it works, please let us know, and I will post further details. (There's no reason to waste bandwidth if it doesn't actually work.)

First, in include/parport.h, find these lines:

1class CParallel {
2public:
3#if PARALLEL_DEBUG
4	FILE * debugfp;
5	bool dbg_data;
6	bool dbg_putchar;
7	bool dbg_cregs;
8	bool dbg_plainputchar;
9	bool dbg_plaindr;
10	void log_par(bool active, char const* format,...);
11#endif

and add these lines immediately below them:

1  // Toggle with reporteof as an option in the conf file for the port in question.
2    bool bReportIOStatusAsEOF;

Next, in src/hardware/parport/parport.cpp, find the lines that read:

1// Initialisation
2CParallel::CParallel(CommandLine* cmd, Bitu portnr, Bit8u initirq) {

and replace them with these:

1// Initialisation
2CParallel::CParallel(CommandLine* cmd, Bitu portnr, Bit8u initirq) {
3    this->bReportIOStatusAsEOF = cmd->FindExist("reporteof", false);

Then, in the same file, find the lines:

1Bit16u device_LPT::GetInformation(void) {
2	return 0x80A0;
3};

and replace them with these:

1Bit16u device_LPT::GetInformation(void) {
2    Bit16u status = 0x80A0;
3    if (this->pportclass->bReportIOStatusAsEOF)
4        status |= 0x40;
5    return status;
6};

I don't have a copy of dBase on my system and can't test whether this fixes the printing problem or not, so please let us know. Again, this is not something I wrote, only something I found.

Note that you'll have to add a "reporteof" parameter to your parallel port setting in the conf for the patch (as written) to have an effect.

A simpler way to test if the "EOF on input" device status bit is really the hangup is to change "return 0x80A0;" to "return 0x80E0;" -- if that works then look at making it fancy. 😉

ripsaw8080 wrote:

Note that you'll have to add a "reporteof" parameter to your parallel port setting in the conf for the patch (as written) to have an effect.

Right! - I've revised my post to add a comment line taken from the source I found, which should clarify this.

Since I can't test this, I hope the original poster can report back. (This is part of a project I've been working on that starts with a version of h-a-l's Megabuild, adds some patches provided here by some extremely generous anonymous sources, plus some other patches found elsewhere, in the hope of providing source code that might be useful for people who use DOSBox for purposes for which it was never intended.)

Also, I suppose something like this should be added to the help string in the //parallel ports section of dosbox.cpp:

1"To turn on detection of eof (required for dBase printing) add parameter:\n"
2"   reporteof \n"

Only if this works, of course!