Only in source. Also depends wether it accesses the ports directly via I/O or in the DOS device way.

Hi h-a-l,

thanks for quick reply. Yep that's what I was afraid of. I don't know much about these things but I am willed to try my best.

I don't know how it's adjusted in the software but I have some information:

1) As I heard the software can't run on Windows XP or newer because direct access on serial ports isn't allowed by these OSs (I think that's the problem which was solved by the porttalk driver)

2) I attached the driver of the adapter from my old DOS-PC. I think the .sys file isn't very interesting but the .opt file seems to have some useful information about how the adapter was configured. Actually I am not able to interpret it. (I renamed .opt to .txt to upload it, in fact it is an .txt file)

Hope that helps,

Whoops, i attached the edited file. I tried to change

1# define DOS device names
2   /D:COM5

to

1# define DOS device names
2   /D:COM3

but that didn't have any effect (the driver isn't loaded in dosbox, i know, but I thought that the software makes use of it, too...however)

So, in the original file it was /D:COM5

Hello again,

sorry for tripple post but I can't see any edit function. I now talked to one of the software developers who said that the program uses the DOS-INT 14 call.

"int86(0x14, &regs, &regs)"

In that case it may help to override the port number at the other side of this BIOS call.
This is the piece of code:

1static Bitu INT14_Handler(void) {
2	if (reg_ah > 0x3 || reg_dx > 0x3) {	// 0-3 serial port functions
3										// and no more than 4 serial ports
4		LOG_MSG("BIOS INT14: Unhandled call AH=%2X DX=%4x",reg_ah,reg_dx);
5		return CBRET_NONE;
6	}

If reg_dx is 4 then you want to change it to 3.

Okay, i hope I understood this right. I found that piece of Code in the dosbox source.

Now you want me to change my software... but unfortunately the programmer of it was kind of lazy and didnt make Backups after every change... Which means that I only have the executable which is up2date and some older source code. I'll try to find the newest source but that may be a problem.

If there's any possibility to change it in dosbox source I would prefer that.

Thanks for help up to here.

Korrupt wrote:

Which means that I only have the executable which is up2date and some older source code.

Have you tried looking at the binary code of the executable with a hex editor? Maybe you'll be lucky, and the relevant byte will be conveniently accessible.

You can compile your own version of DOSBox with this change.

Ah, I think I understood. You meant it like if reg_dx is higher than 3 then change it to 3. Okay, I'm not really into coding but I'll try to find a solution.

Okay, I don't know how to code this. Anyone here into C++ and can fix it the way described?

Korrupt wrote:

Whoops, i attached the edited file. I tried to change […]
Show full quote

Whoops, i attached the edited file. I tried to change

Copy code to clipboard

1# define DOS device names
2   /D:COM5

to

Copy code to clipboard

1# define DOS device names
2   /D:COM3

but that didn't have any effect (the driver isn't loaded in dosbox, i know, but I thought that the software makes use of it, too...however)

I missed this before. Are you saying that even after you make this change, the program is explicitly giving you an error saying that it cannot access COM5?

It is possible you may need to load the .sys driver in the end, in which case you may have to boot MS-DOS inside DOSBox.

Hi jorpho,

I don't need to use the serial adapter which belongs to the driver. I think that loading the driver wouldn't solve the problem because the Int14 call ist used but I may give it a try.

However, still looking for someone who could change

1static Bitu INT14_Handler(void) { 
2   if (reg_ah > 0x3 || reg_dx > 0x3) {   // 0-3 serial port functions 
3                              // and no more than 4 serial ports 
4      LOG_MSG("BIOS INT14: Unhandled call AH=%2X DX=%4x",reg_ah,reg_dx); 
5      return CBRET_NONE; 
6   }

To something like

1If ( reg_dx > 0x3)
2{
3reg_dx = 0x3;
4}

Would it work that way?:

1static Bitu INT14_Handler(void) { 
2   if (reg_ah > 0x3 || reg_dx > 0x3) {   // 0-3 serial port functions 
3                              // and no more than 4 serial ports 
4reg_dx = 0x3;
5      LOG_MSG("BIOS INT14: Unhandled call AH=%2X DX=%4x",reg_ah,reg_dx); 
6      return CBRET_NONE; 
7   }

Korrupt wrote:

Would it work that way?:

Why not try it and find out? 😖

Actually I am ony my way to test it but I got stuck at building following this guide: http://www.dosbox.com/wiki/Building_DOSBox_wi … _C_2008_Express

I did everything the way described. I excluded driver.cpp and driver.h and ne2000 because there were some errors while compiling and I don't need these functions.

Now it says 1>LINK : fatal error LNK1181: cannot open input file 'sdl.lib' but I think I set up the linking in options the right way... 😒

Okay, got this error solved. Still some others to go, hard work to search all the right dependencies as I am an unexperienced guy.

Stay tuned

Wow, after searching all the required files I finally got a working dosbox.exe compiled. Placed it into the dosbox folder and replaced the original one, works like a charm.

Next step is to try my software. I will inform you as there are new results. So far, thanks for help!!

Hello again,

Yesterday I had the chance to test the changes and.... It works!! The "port-forwarding" works and the hardware is recognized and initialized.

Unfortunately there is now a problem with COM1 and COM2. There are a few errors kind like this:

Serial 2: Errors: Framing 0, Parity 0, Overrun: RX 1<IF0:0>, TX: 0, Break 0
Serial 1: Errors: Framing 0, Parity 0, Overrun: RX 2<IF0:0>, TX: 0, Break 0

Rxdelay is set to 300. CPU Cycles is 300.000. Any ideas?

And does anyone know where to find kind of donation details to thank for the provided solution?

Thanks,

300 000 is a lot of cycles... was this software written for a high end pentium originally ?

Hi,

yeah it's propably the problem because it's the first time I used this setting.

Before I used AUTO but on the main screen (programm which communicates via com ports to hardware) the screen build-up was very slow. In addition there is an optional optimation programm (which doesnt make use of the COM ports) which runs under lower CPU Cycles (where te screen build-up is pretty smooth) very slowly. In this optimation software there is much to be calculated and that may be the reason for its slowness. This slowness only appears with low manual cycles, I think with AUTO the dosbox adjusts the value by itself.

I know about the possibility of CPU Cycles up and Down but I thought that this might be the easier solution.

Do you think that the high cpu cycles might be the problem?
Actually i don't know what it was written for but I may ask the original developer.