Doom Pre-Beta

[Quasar]

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.

[andrewj]

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.

[Gez]

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. :)