I am sorry I am no expert in this and you have left me far behind here.
I have no problems with the modifications of the code for the files given, and can recompile it all with these changes as before, by following the simple steps provided by h-a-l-900 in his documentation; but am at a loss to understand where exactly the "reportof" commands or bits of code should be placed.

- In src/hardware/parport/parport.cpp find the line "return 0x80A0;"
- replace with "return 0x80E0;"
- compile again

Hello h-a-l-9000, did so and it works. Fantastic, thank you.
dBase no longer locks up and prints fine.
It also seems to not have affected the printing ability in Dosbox mb6 for the other legacy Dos programs I use.
Just two questions:
1. was the last change you gave the only necessary change or are the changes to the lines in parport.h and parport.cpp given previously by emendelson also required?
2. I presume there was a reason why the original parameters were set a particular way in dosbox mb6, so can this be turned on and off by a command in dosbox.conf if necessary?

Let me ask the same question that potionmaster asked: How much of the code needs to be changed? In my uncomprehending way, I'm guessing that the "reporteof" option becomes irrelevant, but I don't pretend to understand this.

I think other people will be interested in this fix, so it would be very good to know exactly what needs to be done.

Thanks again for sorting this out!

The more involved changes you described allow the "EOF on input" bit of the parallel port device status to be a one (1) if the "reporteof" option is added to the port config in the conf, or a zero (0) if the option is not added. That is somewhat flexible in case there are apps that want that bit to be a zero, although I don't know if there are any.

By changing the return value from 0x80A0 to 0x80E0 the status bit is always a one, and can only be changed by changing the code and recompiling. It's inflexible, but if the status bit turned out not to be what prevents the app from using the port, then changing a single character in one file would be less wasted effort than making the more involved changes across a number of files.

Now that the status bit is proven to solve the problem, you may want to go ahead and apply the more involved changes to have the greater flexibility; however, it's only necessary if it causes a problem elsewhere to have the status bit be a one, which I think is unknown at this point. BTW, having the bit stuck as a one or zero is not necessarily accurate to real hardware, anyway, it's just sufficient for the purpose of the app in question.

That's extremely clear and helpful. Thank you.

I found the elaborate fix in the source code described here:

Link to a project based on MegaBuild 6

For my project, I think I'll use the more flexible option, because I wrap DOSBox in a compiled AutoIt script that writes the conf file before launching DOSBox, and I can be certain that the reporteof option is written (or not written) as needed. It seems also worthwhile to leave it in the source code.

But, now that I think about it, perhaps it would make more sense to make detect end-of-file as the default, and make it an option to turn it off if needed. This would depend on whether any problems occur if the reporteof option causes problems. I don't know whether Ctrl-Z (which is eof, if I remember correctly), is ever going to show up in the middle of some real-world printer output.

Maybe check what real DOS returns here.

h-a-l-9000 wrote:

Maybe check what real DOS returns here.

If I can get a copy of dBASE I'll see what I can find out from my old DOS machine (a ThinkPad 760XL, used for testing and nostalgia only), but I don't think it's something I'll be able to figure out on my own. I hope someone who actually uses dBASE might report.

It has nothing to do with DBase.

h-a-l-9000 wrote:

It has nothing to do with DBase.

OK - the point is finally getting through to me. Apologies for being so slow about this.

Thanks for that very lucid explanation; even I could get the gist of it.

I am still curious what the correct syntax and use of the command "reporteof" has to be in the dosbox-mb6.conf file. I tried a few things but had no luck.

During my searches on different Linux forums for an answer to the dosbox dBase printing problem, I found quite a few other posts from people who were having the same problem, both on Linux as well as in Windows, so I presume there are a number of others who would be interested in this fix. So I guess a more elegant and flexible solution would be nice.

dBase 5 for Dos is a stand-alone program which requires no installation. It is available on an abandonware Site.
I am happy to have my email address provided to you by Vogons so I can provide you with a link if you are still interested in experimenting with dBase 5.

If you want to experiment with "reporteof" (that's report e o f = report end of file), I'd be very grateful.

As far as I understand it, you should start by (1) undoing the change suggested by h-a-l-9000 and ripsaw8080 in their posts, and (2) leaving the change that I spelled out in my post.

Then, in the conf file, find the [parallel] section, and change the parallel1 line to something like this:

parallel1=file append:c:\path\to\file\.prn reporteof

or simply add a space and reporteof to the end of the line that you've already defined for the printer output.

Please let us know if adding "reporteof" makes this work. Thank you!

Now, I am only guessing that this will work correctly, and I hope h-a-l-9000 or ripsaw8080 will correct me if I misunderstand the syntax.

I'll send a private message via the forum if I need some help with dBase. Thank you for offering this.

Hello emendelson, I made the changes as originally instructed by you to an earlier source code of dosbox mb6, just to be sure I only added your recommended code, and re-compiled same.
Results are as follows:
1. If the parallel port lines in dosbox-mb6.conf read:
parallel1=file append:/home/paul/dosdrive/dosbox00.PRN
parallel2=file append:/home/paul/dosdrive/dosbox00.PRT
Trying to print from either parallel port locks up dBase 5.
2. If I change the lines as instructed by you to:
parallel1=file append:/home/paul/dosdrive/dosbox00.PRN reporteof
parallel2=file append:/home/paul/dosdrive/dosbox00.PRT reporteof
Both ports print fine, exactly as if I had applied the mod given by h-a-l-9000.
Therefore the code you gave me works perfectly and as expected.

Hello potionmaster,

A thousand thanks to you for taking the trouble to make that test report your findings. And a thousand thanks to h-a-l and ripsaw for clarifying these things - and of course to h-a-l for providing the parallel port feature in Megabuild.

Thanks again for everyone's help and input. It has been instructive and interesting. And it has sorted my dilemma.
But if someone compiles this version of Dosbox mb6 for Windows, please let me know, I would love a copy for my wife's Windows notebook.

Check your private messages on the forum...

Got it thank you, will get back with results.

re. Dosbox svn wp64 for Windows.
Probably a minor issue, but I cannot get dBase to recognise the printer port.
I have tried a few configurations, the current one is:
parallel1=reallpt realbase reporteof
I have tried the printer output settings for "ps" and "printer"; no dice.
(Perhaps it works in Linux because I am using a spool file "parallel1=file .....")
I also tried Geoworks 3.2a, interestingly this also refuses to print, it says the printer is busy; while it printed fine in dosbox svn daum with the the print output setting set to "printer" and "parallel=reallpt" command . But in this latter version dBase recognises the printer port but locks up on printing (it would be good if you could get the source code for dosbox svn daum and put your mod in that; but I have tried to contact the Korean author a number of times, without luck).
Anyhow, to sum up, Dosbox svn wp64 for Windows prints the directory fine from the command line; only printing in the applications mentioned are no go.

Have you tried "parallel1=file dev:lpt1 reporteof" ?

potionmaster wrote:

re. Dosbox svn wp64 for Windows.

Remember that the build I sent you (Dosbox svn wp64) is completely untested with a real parallel port. You might want to try the Megabuild for Windows first. If it prints correctly to the parallel port, then the problem is in my build.