bds@mtgzz.UUCP (b.d.szablak) (09/11/87)
I've observed strange things happening last night on my ST while working on an assembly program. After spending some time tracking down a bug in the program's bowels, I started finding my program dying (2 bombs) right at startup. Expecting that the problem was caused by a previous crash I powered down (not just a reset) and tried again with the same result. Using MONST I determined that the error was occurring because the value I was using for the TPA pointer (passed on top of the stack at startup) was 0L! I reassembled the program with a TRAP #0 as the first instruction in order to step through the program; the trap was never hit (a later one was though)! I gave up at this point, but it seems that TOS is not starting the program at its entry point. This morning I talked to a friend of mine, and he had seen this same problem himself some time ago. In his case, it went away the next day he started working on this. Has anyone else seen this problem, and does anyone have an explanation?
apratt@atari.UUCP (Allan Pratt) (09/14/87)
in article <3059@mtgzz.UUCP>, bds@mtgzz.UUCP (b.d.szablak) says: > Using MONST I determined that the error was occurring because the value > I was using for the TPA pointer (passed on top of the stack at startup) > was 0L! The basepage pointer is at 4(sp), not "the top of the stack" as you say. This is so it can be taken as the argument to a C procedure like this: _main(basepage) long *basepage; { ... } When the compiler compiles this, it expects that the return address from the "JSR _main" is the long on top of the stack, and the arg is the SECOND long on the stack (at 4(sp)). As for the rest of your problem, I have to assume that it is a misunderstanding between you, GEMDOS, and your debugger. OF COURSE programs are being started at their entry points -- otherwise MONST itself wouldn't work. But when you start the program with MONST, you are introducing another player into the game. I haven't really played with MONST, so I don't know how far to go with that theory. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/ "Yow! Am I interfaced yet?"
bds@lzaz.ATT.COM (BRUCE SZABLAK) (09/16/87)
I have demonstrated to myself that the problem is that the program is not being started at the entry point, but slightly afterwords. The workaround that I'm using is to preface the code with 3 nops. Thus the code that uses the TPA pointer is executed (instead of a fragment of it). The next thing I intend to do is hex-dump the binary and check that the header is set up correctly, and that the 3 nops are actually there.