/Lame execuse for TCP/IP support in DOSBox
I'm wondering if an IPX emulator like KALI loaded in a DOSBox build with an NE2000 and TCP/IP supported would be an alternative for games with issues with DOSBox IPX over UDP.

and for those who like KALI and the like they could load it up and play with it.

That random seed stuff could have to do with the system time. Now, on DOSBox the time drifts (every time some stall happens it is lagging behind a bit). The game might run into problems when the time gets too wrong on the two DOSBox instances.

On the other hand, there is a mysterious bug about the ipxnet ping command. The ping packet is sent back but not always received by the client requesting the ping.

On my homepage there is an old outdated build which uses the Windows IPX directly (the thing with 'ipxnet startni'). However it might be so old that the game doesn't run properly.

To further isolate the issue (on LAN) you could try my build with NE2000 passthrough which loads Novell's IPX drivers and thus is closer to the real thing.

It would be the best to use IP of course but it seems very difficult due to the completely different designs. As I said, I dont know anything about such network programming - but using the IPX protocol in Windows XP may not take so much time and effort and would allow a lot of people to play such games on much more recent machines before a perfect solution via IP is found.

h-a-l-9000 wrote:

That random seed stuff could have to do with the system time. Now, on DOSBox the time drifts (every time some stall happens it is lagging behind a bit). The game might run into problems when the time gets too wrong on the two DOSBox instances.

Correct me if I am wrong, but IF that is the core of the problem, then using native IPX in some form would not alleviate the problem, right? The 2 systems would still drift apart time-wise, and end up being out of sync.

-Bad post-

Would it be possible to somehow sync the Dosbox-clocks via the emulated IPX?

Hal, the ping request is because, when the ping command runs, it sets up a separate listener loop WHILE THE NORMAL LISTEN LOOP is still running. That's why it doesn't always show up; sometimes it isn't picked up by the ping command's loop.

Can you give me any more info (specific src files to look at, etc) on the time drift?

Ah, thanks. I'll make a patch (if you don't already have one).

In latest CVS Qbix added a timesync mechanism which can be enabled at comile time: DOSBOX_CLOCKSYNC in bios.cpp.

If that fixes it I'll be a weird mixture of happy and agitated. Haha. I'll try to get out a new binary tonight with the reliable packet delivery and timesyncing.

PS - I don't have a patch for the ping thing, unfortunately.

Patch for ping

Alright, I recompiled the EXE with Qbix's clock sync (I made it update slightly more frequently than he had it for this version, just because of how my computer was responding and lagging) and then ping adjustment provided by HAL.

The version stamp on your dosbox window should read 0.72walt_b5 if you've properly using this executable.

Note that you should probably only use this executable over relatively lossless connections, or you're going to wrack up a lot of lag very quickly.

Let us know how it turns out!

As a sidenote, I get a "Transfer Stack Overflow error at interrupt 08h" or sometimes 09h . . . Could this perhaps have something to do with the fact that I'm running two instances of dosbox off the same binaries and CD? Any other ideas as to what might be causing that, anyone?

--Don't use this binary; another will be out soon--

> Transfer Stack Overflow error at interrupt 08h

You are probably using cycles=auto or max. This should have been fixed in CVS though. (with auto/max the speed sometimes bounced down to a very few amount cycles which was not enough for the game to process interrupts in time)

Apparently I need to update my repo . . . I'll post another binary when I've done that.

...

Ok, it looks like that fixed that issue. At least, it fixed it if I up the minimum cycles from 100 to 1000. So now, I present 0.72walt_b6. Enjoy 😀 Let us know if it works, Philzero (and Bobo, if you're still looking at this).

As a note, I'm aware of a bug where alt+tabbing to DosBox and then selecting a text field within Fragile Allegiance will lock the game until you press the tab or escape key within dosbox. I have no idea why it happens, but that's something to be aware of.

Hi ghosthammer,

it seems to run fine (at least for a short time). I restocked the fridge with everything unhealthy and will give it a try tomorrow all day long. I really hope this will work (and 20h of FA dont cause instant death 😉 ).
Thanks for your help, I will let you know if it worked.

Well, a friend and I played a short 2 hr game tonight and it worked good, which is great because before we only got out to 20 minutes! Uhm, I did get a render crash a few times during testing . . . I'll post that in a separate thread though.

Allright, it worked perfectly! We had about 20h of undisturbed fun with this great old game. Thank you very much for your help!

Ok this is my first post and I know almost nothing about IPX and port forwarding and such like

I am just a simple Fragile Allegiance fan its one of my all time favourites
and recently I was reaqauinted with this much loved games.

My friends are equally impressed with the game specially those I used to link in a LAN with on the old serial link

But of course there was much anguish, as very often the game would bomb out on us.

If I read rightly the problem seems to have been fixed. Yeah lota of whoopin an holoring

Now these days we havent the same liberty to get together in someones house on a LAN so this dosbox and ipx system seems to be the sollution

One problem I have no clue as to how to get this thing going,
big sigh

I have however managed to to get a single game going with dosbox 😀

But when I go for multiplayer No joy

Can anyone help