walker@xanth.UUCP (04/08/87)
I recently bought the Microsoft Macro Assembler version 4.0 and I am trying to get it working on my Tandy-1000. The assembler works, but I am having trouble with Symdeb. When I run this program, it starts up and prints the header and cpu type, then locks my computer up. The disk keeps spinning, but the computer will not respond to anything, even control-alt-delete. Has anyone else had a similar problem? Does anyone know of a way to fix it? Any help would be greatly appreciated.
toma@tekgvs.UUCP (04/09/87)
In article <799@xanth.UUCP> walker@xanth.UUCP (Mike Walker) writes: > > I recently bought the Microsoft Macro Assembler version 4.0 and I am >trying to get it working on my Tandy-1000. The assembler works, but I am >having trouble with Symdeb. When I run this program, it starts up and prints >the header and cpu type, then locks my computer up. The disk keeps spinning, >but the computer will not respond to anything, even control-alt-delete. > > Has anyone else had a similar problem? Does anyone know of a way to >fix it? Any help would be greatly appreciated. I reported this problem, and its fix, to the net over a year ago. I am suprised that Microsoft has not fixed it because the certainly know of the problem -- it is fixed and explicitly documented in their CodeView debugger. Symdeb runs in two modes IBM and non-IBM. The Tandy 1k must run in the non-IBM mode (which is unusual, considering its high level of compatibility). They supply a command line switch to force IBM mode for machines it thinks are non-IBM (particularly a Compaq), but the have no switch to force non IBM mode for systems that it thinks are IBM. How does it decide? Why it does the version system call and if the system is running PC/DOS then it is an IBM, if it is MS/DOS then it is not! On my Tandy 1k, I had switched from the Tandy supplied MSDOS V2.11 to PCDOS V3.1 when I added a 20 meg hard disk. Then I bought the assembler and found that SYMDEB did not work. The fix -- rename the file from SYMDEB.EXE to SYMDEB.COM. Using DEBUG, search for the system call (30H). Then patch it so that it always looks like MS/DOS. Save the patched code and rename back to SYMDEB.EXE. You can decide how to patch it -- after all you know the machine language! BTW, the reverse engineering necessary to fix the program, and the patch itself are in violation of the license "agreement", so you will be performing a criminal act in order to make the program useful. Tom Almy Tektronix, Inc. (Tektronix has no connection with this, it is my personal copy)