It does more disassembly of the special P2 instructions (most of them, but not all).
The disassembly is only simple the D & S operands are still shown even for those instructions that do not have these operands (eg setpz which only has a D/#n operand).
A classic look at the ROM shows some of these instructions. For Listing the code from cog or hub, the address determines if it is in cog by being =<$1FF. Therefore, this means that ROM addresses (hub) below $200 cannot be displayed. But a quirk where the P2 ignores address bits >$1FFFF (>128KB) can be used to display these addresses. eg: use $80000 and this will display from $0 in hub. (*8000,32L2<cr>) (32 lines is the max that I permit to be displayed at a time but can be easily changed)
Sapieha: I have not yet had time to look at your latest code - I will do that now and thanks again.
Just a note that I chased an error that turned out to be some sort of end of line problem in the source - multiple lines became mixed together and those instructions were then ignored by the pnut compiler. Currently I am unsure where this occurred (Notepad++ or pnut), so it's just a heads up in canse someone else finds a problem like this.
Sapieha changed the V command and those changes are included - thanks Sapieha.
Almost all instructions are decoded. Those few are marked with * except for the cmp/sub, cmpr/subr, test/and, testn/andn.
I have yet to properly decode the three repx instructions properly. Please report any errors, in particular wrong decoding.
Note that because this is designed to be a simple disassembler, operands are not removed from those instructions that don't/cannot use them. The same applies to the conditionals (setindx/fixindx).
It is ready for you to add your pasm code to this debugger. All sample code is removed from the cog (except a debug call).
This simplifies the program for the user to start with. All functions still remain in the LMM hub code.
Just paste your program into the cog section and you are ready to go.
The debugger uses cog $1E0-$1F5 ($1F6-$1FF are special registers in the cog).
I have been thinking about adding a single breakpoint and what that entails.
I think I will restrict to 1 breakpoint only. It can be preset during compile time - this saves a separate call to the debugger to setup a breakpoint.
When a breakpoint is installed, the instruction is saved in a separate cog location, and a "call breakpoint" instruction is installed in its place.
Once the breakpoint is reached, control is passed to the debugger. After performing whatever commands are required (within the debugger), the user may either "remove breakpoint", "set new breakpoint", or "keep breakpoint", and then "return", "restart", or "start" the user program (or quit or run the rom monitor).
I have been thinking about adding a single breakpoint and what that entails.
I think I will restrict to 1 breakpoint only. It can be preset during compile time - this saves a separate call to the debugger to setup a breakpoint.
When a breakpoint is installed, the instruction is saved in a separate cog location, and a "call breakpoint" instruction is installed in its place.
Once the breakpoint is reached, control is passed to the debugger. After performing whatever commands are required (within the debugger), the user may either "remove breakpoint", "set new breakpoint", or "keep breakpoint", and then "return", "restart", or "start" the user program (or quit or run the rom monitor).
Hmm... maybe add an primitive for BREAK, that you can resume from? Forgive me if this is already implemented, I have not tried your debugger yet.
Yes, you will be able to continue from a break, either by leaving the existing break in place, setting a new break, or by removing the break entirely. You can also override the resume address to continue anywhere within the cog. There will be a new call for the break so that only a single call is required (ie no parameters).
I have worked out how to implement this so it is only time to do it.
Here is the latest version 0.90
* Code starts at $E80 (not $1000) hub.
* Disassembly has not been corrected for the new P2 instruction changes
* Compile pasm and download using the new pnut.exe using F11 - there is a 5 second delay to allow for you to PST to start.
Example commands..
E80.FFFL2<cr> disassembles hub $e80-fff
0.1EFL2<cr> disassembles cog $000-1EF
1000,50L<cr> lists hub $1000 for a length of 50 in bytes and ascii (L & L0 are equivalent)
? displays help
The basic format is
{addr1}.{addr2},{length}{command+parameter}<cr>
The last code posted above does not correctly reflect the version no.
If you wish to list memory (L command) then all addresses below $200 are treated as cog memory and addresses 200 and above are treated as hub. However, it is possible to "trick" the debugger into listing the hub addresses below $200 by specifying $20xxx because this specifies hub >128KB and the addresses wrap. So 20000,20L2<cr> will list (disassemble) the first 20 longs of hub memory. (note not all instructions are correctly disassembled, particularly those whose opcodes changed in the new fpga code)
Currently the debugger occupies $1E0-1F5 of the users cog space. All remaining code runs from hub space as LMM.
The debugger code released includes lots of example calls to the debugger from user code (fills user space). This can be removed/deleted. Occasionally I will release a minimal version which removes all example code.
Comments
Most instructions for opcode '000011' are now decoded. For example, see the disassembly of the rom monitor at $700... Thought I should note that the operands do not reflect the specific instructions. It is just a simple disassembler, at least for now anyway.
LSD_084.spin
It does more disassembly of the special P2 instructions (most of them, but not all).
The disassembly is only simple the D & S operands are still shown even for those instructions that do not have these operands (eg setpz which only has a D/#n operand).
A classic look at the ROM shows some of these instructions. For Listing the code from cog or hub, the address determines if it is in cog by being =<$1FF. Therefore, this means that ROM addresses (hub) below $200 cannot be displayed. But a quirk where the P2 ignores address bits >$1FFFF (>128KB) can be used to display these addresses. eg: use $80000 and this will display from $0 in hub. (*8000,32L2<cr>) (32 lines is the max that I permit to be displayed at a time but can be easily changed)
Sapieha: I have not yet had time to look at your latest code - I will do that now and thanks again.
Below is a sample dump of the Rom Monitor
LSD_085d.spin
Just a note that I chased an error that turned out to be some sort of end of line problem in the source - multiple lines became mixed together and those instructions were then ignored by the pnut compiler. Currently I am unsure where this occurred (Notepad++ or pnut), so it's just a heads up in canse someone else finds a problem like this.
Sapieha changed the V command and those changes are included - thanks Sapieha.
Almost all instructions are decoded. Those few are marked with * except for the cmp/sub, cmpr/subr, test/and, testn/andn.
I have yet to properly decode the three repx instructions properly. Please report any errors, in particular wrong decoding.
Note that because this is designed to be a simple disassembler, operands are not removed from those instructions that don't/cannot use them. The same applies to the conditionals (setindx/fixindx).
LSD_086.spin
It is ready for you to add your pasm code to this debugger. All sample code is removed from the cog (except a debug call).
This simplifies the program for the user to start with. All functions still remain in the LMM hub code.
Just paste your program into the cog section and you are ready to go.
The debugger uses cog $1E0-$1F5 ($1F6-$1FF are special registers in the cog).
LSD_086min.spin
I think I will restrict to 1 breakpoint only. It can be preset during compile time - this saves a separate call to the debugger to setup a breakpoint.
When a breakpoint is installed, the instruction is saved in a separate cog location, and a "call breakpoint" instruction is installed in its place.
Once the breakpoint is reached, control is passed to the debugger. After performing whatever commands are required (within the debugger), the user may either "remove breakpoint", "set new breakpoint", or "keep breakpoint", and then "return", "restart", or "start" the user program (or quit or run the rom monitor).
Any comments??
Hmm... maybe add an primitive for BREAK, that you can resume from? Forgive me if this is already implemented, I have not tried your debugger yet.
I have worked out how to implement this so it is only time to do it.
* Code starts at $E80 (not $1000) hub.
* Disassembly has not been corrected for the new P2 instruction changes
* Compile pasm and download using the new pnut.exe using F11 - there is a 5 second delay to allow for you to PST to start.
Example commands..
E80.FFFL2<cr> disassembles hub $e80-fff
0.1EFL2<cr> disassembles cog $000-1EF
1000,50L<cr> lists hub $1000 for a length of 50 in bytes and ascii (L & L0 are equivalent)
? displays help
The basic format is
{addr1}.{addr2},{length}{command+parameter}<cr>
LSD_090.spin
If you wish to list memory (L command) then all addresses below $200 are treated as cog memory and addresses 200 and above are treated as hub. However, it is possible to "trick" the debugger into listing the hub addresses below $200 by specifying $20xxx because this specifies hub >128KB and the addresses wrap. So 20000,20L2<cr> will list (disassemble) the first 20 longs of hub memory. (note not all instructions are correctly disassembled, particularly those whose opcodes changed in the new fpga code)
Currently the debugger occupies $1E0-1F5 of the users cog space. All remaining code runs from hub space as LMM.
The debugger code released includes lots of example calls to the debugger from user code (fills user space). This can be removed/deleted. Occasionally I will release a minimal version which removes all example code.