MBECK@AI.AI.MIT.EDU ("Mark E. Becker") (01/08/88)
Hello All -
I figure hundreds of people have already run into this little
problem.. and it has already been solved.
I am trying to mate BYE339 (yes, I know it's been superseded..
but 502 wasn't out when I started this) with RBBS 4.102 . And things
aren't going well. There is some interaction between the two which is
corrupting memory and making my life miserable.
Surely this has been done before.. how to debug an RSX after it's
been installed? Is there some way to get SID or Z8E to accept an
offset to a symbolic label so I can reach in and see which program is
guilty of memory bashing?
I'm using BDS-C v 1.50a for the RBBS compile.
Regards,
Mark Becker
MBECK@AI.AI.MIT.EDUW8SDZ@SIMTEL20.ARPA (Keith Petersen) (01/08/88)
The latest version of BYE is BYE510. It is available from SIMTEL20 as: Filename Type Bytes CRC Directory PD1:<CPM.BYE5> BYE510.LBR.1 BINARY 174208 2DA0H The RSX bugs have been fixed in this version. --Keith
bridger%rcc@RAND-UNIX.ARPA (Bridger Mitchell) (01/09/88)
Most debuggers use the bdos (rather than the bios) for terminal input/output, so the first thing you have to do is avoid re-entering the bdos when you are tracing/trapping. You might try this approach under the debugger: 5: jmp rsx_entry 100: program: ... xx: call 5 ;bdos call at routine causing trouble ... Change the 'call 5' to 'call rsx_entry'. Set breakpoints at 0000, the program's exit routine, and xx. Set up command line and execute from 100. When you hit the xx trap, set other breakpoints in the rsx at important spots, then single-step into the rsx to watch things. You can get symbols for the rsx by assembling it once with origin == rsx_entry and loading that symbol file under the debugger. Some debuggers will cummulate symbols from several files, so you can also load symbols from the transient program if you have them. If you do much debugging, you may want to patch the debugger to use bios i/o. --bridger