Return to previous page ｜ Return to menu ｜ Go to next page
- When the control is transferred to the debugger instead of the user program, the two interrupts of level 2 autovector and level 3 autovector are replaced with the following routines.
interrupt: move.w # -1, SCSP_SCIRE
Rte
Therefore, as long as you follow the rules of sound tools (SCSP interrupts use only level 2 and 3), interrupts are not interrupted to the user program while waiting for the debugger.
-
■ Memory hidden by SSBug
- SSBug specially handles the first $ 80 bytes of memory to hook into the user's vector, and the $ 000000- $ 00007F memory seen by the debugger is not actually $ 000000- $ 00007F on the target. Therefore, the following restrictions apply to the memory area of $ 000000- $ 00007F.
If you use - ICE, etc., it may seem inconsistent.
- User program code cannot be placed.
- Dumping memory from SSBug does not allow you to see the exception vector that SSBug hooks.
-
Critical hours
- There is a critical time for debugger operation in the current version, such as when an emulator break such as a hardware break occurs and a CPU exception including a software break or trace execution occurs almost simultaneously. Currently taking measures.
-
SCSI noise
- SSBug SCSI communication may get on the analog output of the sound board as noise. If the noise gets in the way, try opening some kind of dialog. While the dialog is displayed, SSBug does not communicate with the sound board.
-
■ About linefeed characters
- The line feed character of text files (all batches, symbols, and hex files) handled by SSBug can be CR only (Macintosh) or CR + LF (MS-DOS, etc.).
However, EOF characters in CP / M and MS-DOS are not supported.
Return to previous page ｜ Return to menu ｜ Go to next page