3 ms·
A useful debugging technique on the VZ200 was to locate the stack in video memory. The display would be a mass of snow when the program was running, since the
by femto 14y ago
A useful debugging technique on the VZ200 was to locate the stack in video memory. The display would be a mass of snow when the program was running, since the CPU activity left hardly any cycles for the video controller to access screen RAM, but when the program crashed its state could be read directly off the screen.
- jgrahamc 14y agoNice. I've used this type of technique in other situations where very high-speed debug output is needed. At one job we had a machine code ring buffer implementation that could be called via a software interrupt (INT 3 I believe with a single character in AL) to write a single byte of debug information. This could be used when tracing a program's execution. When the program crashed the ring buffer could be examined using a system debugger (typically Soft-ICE) to see what state it was in. Very useful when it was critical to get tracing information in a way that had minimal timing impact.
- femto 14y agoI'm using this exact technique in my daily work right now! :-). It's an embedded DSP doing real-time signal processing for digital radio, and the technique you describe allows the execution flow leading up to a crash to be determined, without the timing jitter introduced by the "real" debugger.
- lgieron 14y agoSomething similar was also used by C64 cracker groups adding their intros to cracked games. Before the intro ran, user saw a few seconds of random characters on screen - most likely a buffer for a decompression algorithm. In this was case it wasn't done to ease debugging - it's just that the game itself occupied almost all available memory and the only area left that was big enough was the screen buffer. Plus, the resulitng effect itself looked Matrix-like :)