Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Quasar

Doom Pre-Beta

Recommended Posts

I am taking a cursory glance through the press-release pre-beta in IDA Pro. There are a *lot* of differences that go way deeper than the seeming cosmetic changes between this and the final game.

But there's an annoyance with some of the code that we cannot work out. Watcom seems to have inlined strcpy everywhere, and in the routine is this code:

cseg01:00023900                 push    edi
cseg01:00023901 loc_23901:                              
cseg01:00023901                 lodsw
cseg01:00023903                 test    al, al
cseg01:00023905                 jz      short loc_2391A
cseg01:00023907                 stosw
cseg01:00023909                 test    ah, ah
cseg01:0002390B                 jz      short loc_2391B
cseg01:0002390D                 lodsw
cseg01:0002390F                 test    al, al
cseg01:00023911                 jz      short loc_2391A
cseg01:00023913                 stosw
cseg01:00023915                 test    ah, ah
cseg01:00023917                 jnz     short loc_23901
cseg01:00023917 ; ---------------------------------------------------------------------------
cseg01:00023919                 db 0A8h ; ¿
cseg01:0002391A ; ---------------------------------------------------------------------------
cseg01:0002391A loc_2391A:                              
cseg01:0002391A                 stosb
cseg01:0002391B loc_2391B:                              
cseg01:0002391B                 pop     edi
IDA won't deal with any code containing this as a function because it complains that there is an illegal instruction. The A8 db you see is initially interpreted as a "test al, 0AAh" instruction; however, when vv ran this code in the debugger, that instruction never executed. Instead the the AA byte executes as a stosb.

So my question is, does anybody have a clue in hell why that A8 byte is in there, and what might be done to clean it up?

Our best conjecture at this point is that it is some kind of cleverness in the compiler that is changing the interpretation of the stosb instruction into an inconsequential test when the final jnz doesn't jump, which simply doesn't happen here, but technically could under different conditions. IF this is true, changing it to please IDA Pro is going to be difficult for me.

Share this post


Link to post

If I read 386intel.pdf correctly, A8h will be a TEST instruction using the next byte (the stosb) as the immediate data.

In other words, I reach the same conclusion as you that is was a clever way to ignore the stosb instead of doing a short jmp.

UPDATE: since the loop is once unrolled (it does two words in each loop), you have room to replace it with simpler valid code.

Share this post


Link to post

If you take also a look at alpha 0.2 and alpha 0.4, I'd be interested in knowing what exactly does the engine do with the VIEWINFO, HIGHBLIT and COLORS15 lumps. :)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×