The American version, UltraBots, runs fine.

I tried to debug it with DOSBox debugger. I acts strangely because
it code jumps to 0000:0002 address which is normayi Interrupt Vector Table (DIV0 segment address).
The game before this farr Call directly calls INT 3 which is not supported by DOSBox probably to prevent debuggers in normal DOS Mode.

Do You have some suggestions how to continue this debugging or
do You know where the problem is?

Ognjen Milic

Directly calling int3 works fine, this is a nop in dosbox as well (just
shows some debug message to denote this case).
Most likely the address of the far call was computed wrongly,
you should keep an eye on where this value comes from.

I have prcessed xeno.exe trough Borland Turbo debugger and revealed this:

TD: call far [00b4] ds:00b4=28fa:1b6c
DoxBox: call far [00b4] ds:00b4=0000:0000

somewhere this had been or initialized to zero by mistake or exe
unpacking code which processes in the
begining is executed badly or something else?

I'll try in next days to inspect where in the code these data values change.
Do You have any suggestions?

Ognjen Milic

When the game is started in dosbox (bpint 21 4b), set this memory to
some values (like 1234:5678) and see if they change.
Also (if this is possible) try to set breakpoints on memory access or
memory change in TD for that memory dword, if TD can't do that either
try to use a different debugger (softice/dos, cup386) that works with
the game, or watch the memory region when tracing the game.

If you have some suspect, like DOS should have an effect on the
address, boot up msdos inside dosbox (using the image support)
and see if the game works there.

Good luck 😀

I traced this memory location with DOSBOX debugger and discovered
that it is set to zero with all other nearby locations durin unpacking code.
It seem unbelivable, but in the unpacking code (which I have dissasembled and tranlated to C language with memory redirected to file) ther is no interupt calls, I/O accesses or some DOS environment consulting. Just pure 8086 code.
I can't belive that there are mistakes in DOSBOX 8086 instructions emulation.

Ognjen Milic

I discovered malfunctioning instruction

mov al, es:[bx+di] where es:[bx+di] points to 0x2ad7 loads zero
into al and stosb puts zero in correct location.
It loads zero into al no metter on which data es:[bx+di] points to.
I have checked this in 20 step loop and everytime it had loaded zero.

Hope this helps to DOSBox development.

I'll try to debugg NBA Live 95 which I have posted to
in next days.

Ognjen Milic

milicognj wrote:

I discovered malfunctioning instruction […]
Show full quote

I discovered malfunctioning instruction

mov al, es:[bx+di] where es:[bx+di] points to 0x2ad7 loads zero
into al and stosb puts zero in correct location.

It loads zero into al no metter on which data es:[bx+di] points to.
I have checked this in 20 step loop and everytime it had loaded zero.

No, you did not.

The DOSBOX v0.63 debugger version shows that the instruction in question with the ES segment over-ride:

1   mov al, byte ptr es:[bx+di]   ; opcodes= 26 8A 01

It works just fine. The DOSBOX x86 emulation is not your problem.

dvwjr

Of course I know that 26 is es segment prefix and I didn't messed opcode
with data where es:[di+bx] points to

so here's the code of the loop

lab: mov al, es:[di+bx] ;es:[11399]=412a
stosb
loop lab

But when I added manualy bx and di and it was not 412a that
are pointed, but the real data stored in al. Thanks.

So it is small mistake in debugger and not in DOSBox sorry.

I'll try harder to reveal what is happening.
It's annoying because data that should not be set to zero
are set to zero and as I mentioned earlier it's simple and short
8086 code (298 bytes).

If you are interested I can send You exe filea and asm code of
unpacker.

Ognjen Milic

Finally I made the game work!!!!

This is what is happening

there is procedure for memory allocating

it first asks for info about largest free block
mov ah, 48
mov bx, ffff
int 21

and then allocate that ammount of memory
push bx
mov ah, 48
int 21
pop bx

then some cod is executed and again largest block info is queried
mov ah, 48
mov bx, ffff
int 21

DOSBox returns 0000 int bx
the game tries to allocate 0 paragraphs of memory which of course leads
to failure and CF=1.

When CF is set game (with jb) skip necessary part of code and breaks

I have manualy changed CF (with SR CF 0) and game started!

What can be done to get the game running without debugging?
To patch the game or DOSBox can be changed to clear the CF
when 0 paragrafs are allocated?

Ognjen Milic

P.S. Sorry for bad instruction false alarm because the earlier mentioned data should be set to zero by unpacker, but their proper setting is skipped in described way.

First of all thanks for debugging this (couldn't find that game anywhere).

I'll check the behaviour against msdos, i guess this is handled as
special case.

The current behaviour of dosbox wrt zero page allocates is
correct (at least 16 bytes for the MCB header would have to
be available), so it must go wrong somewhere before already.

ultrabots & xenobots can be found with emule. They are 1.24/1.39MB.

I don't have such software installed for some reasons.

Anyways, it crashes the same way under dosbox+msdos6.22 and
bochs+msdos6.22 when booting clean and starting the game
like xeno.exe V N. Other configurations crash the game as well,
so it'd be interesting if this happens on an older dos version as
well.

An easy workaround is to start the game with "lh xeno" (umb=true
in dosbox.conf) as the second allocation is directed to the low dos
memory, which is still free at that point. This is exactly the only
situation where i got the game to run under msdos6.22 as well.

I have two copies of ultrabots /w ultra.exe dates 1/21/93 & 3/15/99(ea re-release as a "cd-rom classics"). The re-release runs in dosbox as is & the original release crashes. Neither need loading high as wd describes to run on a real machine. I don't have a xeno copy yet to compare.

As i said i did not test it on a real machine, just booting dos
inside dosbox and bochs.

The version I reported on is the floppy version of Ultrabots (probably 1/21/93). I wonder what's different with the re-release and the European version (Xenobots)?

Roger that wd. I now have a copy of xenobots which is dated 5/27/93; it crashes like ultrabots 1/21/93.
BTW, I tried qemu, it doesn't work with any version.

Tried xenobots on a real machine as well, crashes just fine.

Ih8regs, could you please try the following with the old
version of ultrabots: boot clean (like no config.sys/autoexec.bat)
start the game with/without sound.
And could you check if those games that crash dosbox work
(under dosbox) when you use something like "lh xeno"?
(where UMBs are enabled)

Tried it with prefetch queue enabled, doesn't affect the
crashes, so the cpu part shouldn't matter. Will try to
find a different dos version, maybe there's some reason
for an additional small free MCB.