Borlands Tasm 4.1 generating faulty output problem

7 views
Skip to first unread message

R.Wieser

unread,
May 25, 2021, 10:08:03 AMMay 25
to
Hello all,

I'm using Borlands Tasm 4.1 and TLink 7.1.30.1 on XPsp3 in a CMD box, and
have run in a situation where NTVDM throws an error because of an unknown
opcode.

It looks like that it has nothing to do with my programming (jay !), but
with either of the above programs. Below are the relevant parts from the
executable, the object and the list files.

The problem is the 0x00 injected at address 0x05D1 in the .EXE and address
0x09AA in the.OBJ, but *not* the .LST file (at 0x05D1). Among others it
causes the JMP to be one byte short, pointing to the last byte of the
command before the actual targetted command (causing the NTVDM to barf).

Notice that the second commandbyte at 0x05D3 in the .EXE does not match the
one at 0x09AC in the .OBJ file (presumably because of the assemble-time
fixup of the argument of the PUSH at line 1668 of the .LST file).

Remarkably, when I place a NOP (or any byte for that matter) just below the
"jmp @@CmdGetDir2" at line 1664 in the .LST file the problem fully
disappears.

-- .EXE
162E:05C7 683412 PUSH 1234
162E:05CA 6A00 PUSH +00
162E:05CC E836FF CALL 0505
162E:05CF EB49 JMP 061A
162E:05D1 00FF ADD BH,BH ;<--
162E:05D3 F4 HLT
162E:05D4 9D POPF
162E:05D5 01E8 ADD AX,BP
162E:05D7 D0FA SAR DL,1

-- .OBJ
15C7:09A0 683412 PUSH 1234
15C7:09A3 6A00 PUSH +00
15C7:09A5 E836FF CALL 08DE
15C7:09A8 EB49 JMP 09F3
15C7:09AA 00FF ADD BH,BH ;<--
15C7:09AC 3696 XCHG AX,SI
15C7:09AE 01E8 ADD AX,BP
15C7:09B0 D0FA SAR DL,1

-- .LST
1 1659 05C7 68 1234 PUSH 1234H
1 1660 05CA 6A 00 PUSH gcCOM
1 1661 05CC E8 FF36 CALL CommWriteBlock
1662 05CF EB 49 jmp @@CmdGetDir2
1663
1664 ; <--
1665
1666 ;---------------
1667 05D1 @@CmdGetDir1:
1668 call TTYHexWord,[gBlkBuf].BLK2FLE_wAttrib
1 1669 05D1 FF 36 0196r PUSH [gBlkBuf]. BLK2FLE_wAttrib
1 1670 05D5 E8 FAD0 CALL TTYHexWord

The question: does anyone recognise it and knows how how/with what to fix
it. Likely an update of either or both of the above files ...

Regards,
Rudy Wieser


Reply all
Reply to author
Forward
0 new messages