Yes, Bill
I am going to take a better look at the functions of chips monitor. Just some of the basics may be useful, particularly the xxxx.xxxx command to examine memory (DUMP mode).
And DUMP from the Cog will be neat.
Postedit: Just been looking thru Chip's P2 ROM Monitor program and noticed a quirk in that his Tx routine can send 2 characters in "x". This would also work for 3 chars (but not 4). I added an AND x,#$FF to ensure the user didn't have bits b31..8 erroneously set. I am going to think more about this, as it saves a bit of code.
Also saw an interesting way of using a multiple entry point to accumulate a value. The usual way to do this requires the value to be zeroed first, then a set of add x,#1 intructions to accumulate in x. Chip's way (see cmd_byte/word/long labels) does not require this, by using the Z flag which is set Z=0 on entry.
I now have cog dump working. Just need to tidy the code before posting. Had me stumped for a while - it is a little convoluted in how you do this - once understood, the solution was quite easy.
I have a other few things to do for a few days, so in the meantime...
The user can use Rx (reads a character from the serial port - this is half duplex and no buffers, so it waits for a character) to read a character and do whatever. In my demo, I use <esc> to reload the ROM Monitor (which required a <space> to autobaud).
This is what I think is next...
New call RXSTRING
Receives a serial stream of characters to a hub buffer.
The receive string is terminated by a <cr> which optionally can be copied to the buffer.
The hub buffer will be terminated by a <nul> = $0.
New call MONITOR to invoke my minimal version of the ROM Monitor (in LMM) so that at the end, the user can return to the user cog program. So this becomes similar to the ROM Monitor, but the users pasm program is stalled in the background.
User cog and hub data can then be viewed/changed.
Control can then be returned to the users program by <esc>
These are the commands I am thinking of adding to my monitor section (subset of the ROM Monitor commands)
View (single address, <space> displays the next line) - can view both hub and cog addresses
Here is v0.25.
It can now dump both cog and hub addresses, and receive characters.There is still some code tidyup to do to reduce the cog footprint.
Included is a demo pasm program that calls these features.
There is a problem that I think may be in pnut.exe. It seems that pnut can only compile up to 2KB because hub is only loaded up to $165F followed by 32 bytes I think is inserted by pnut.
Here is v0.30
It inserts 0's to $E80 and fillers to position the HUB LMM code at $1800+
Use pnut to compile and "p2load -v xxxx.obj -s"
Note the output format I am currently using does not work properly with p2load terminal mode, so I have resorted to PST (think it may be me using <cr> w/o <lf>).
You may consider to use PropTerminal (in the Sticky thread). It also allows to load the .OBJ files that are generated by PNUT, also if they are bigger then 2 kB. The loader works via to the monitor, so first go the monitor then choose in PropTerminal menu: File->upload.
Here is v0.30
It inserts 0's to $E80 and fillers to position the HUB LMM code at $1800+
Use pnut to compile and "p2load -v xxxx.obj -s"
Note the output format I am currently using does not work properly with p2load terminal mode, so I have resorted to PST (think it may be me using <cr> w/o <lf>).
Thanks Andy. I will give it a try. That is a nice way to load it up from the terminal.
Sapieha: I may add decimal and binary later. Then it could be used as a general purpose I/O in the OS.
But for now, I am interested in being able to debug an operational P2 program. So I need to add readstring, followed by the ability of the debugger to use the readstring to display/modify cog and hub ram under user (terminal) control in addition to program control. I also want to add trace/singlestep control, like I did in my P1 zero footprint debugger.
I need all this to help me debug my version of the spin interpreter.
Andy: I gave propterminal a try. Unfortunately I simplified my code to insert 0[e80] at the beginning and used the -s option in p2load to skip these 0's. This then gives correct hub addresses without needing to add the offsets. In LMM there are quite a number of these.
Would you be able to make an option to do this too?
I see you have rows and columns specified in your ini file. Can I increase the rows/lines? The ability to scroll back in PST is quite an advantage at times.
I uploaded version 0.2 of Prop2Terminal to the sticky thread (to the same post as before, so it is easy to find).
This version allows to specify the target hubaddress for *.OBJ files, so they can now be loaded to every address in hub. If you specify an address < $E80 the bytes until $E80 are skipped, so the equivalent to -s of P2load ist to specify 0 as target address.
You can increase the cols and rows parameter in the .ini file, but you just get a bigger window, no scrollbars.
Thanks Andy.
Are you using the rom monitor to download your code? You may have seen Sapieha is looking for this mode (with using the input file in the rom monitor format as can be used by Ctl-L in the monitor and copy/paste/save).
I uploaded version 0.2 of Prop2Terminal to the sticky thread (to the same post as before, so it is easy to find).
This version allows to specify the target hubaddress for *.OBJ files, so they can now be loaded to every address in hub. If you specify an address < $E80 the bytes until $E80 are skipped, so the equivalent to -s of P2load ist to specify 0 as target address.
You can increase the cols and rows parameter in the .ini file, but you just get a bigger window, no scrollbars.
Andy
Hi Andy,
I'm afraid I haven't been following Prop2Terminal. Is this a cross-platform terminal program? What is it written in? I'm wondering if I can combine it with p2load to make a GUI version of the loader with a good terminal emulator built in?
I'm afraid I haven't been following Prop2Terminal. Is this a cross-platform terminal program? What is it written in? I'm wondering if I can combine it with p2load to make a GUI version of the loader with a good terminal emulator built in?
Thanks,
David
Propterminal for Prop1 is available since years. It was made before we had PST. The main purpose is the emulation of TV_Text, Keyboard and Mouse via a PC, so you don't need the physical devices to test Spin code. Later I added a "normal Terminal" mode.
It is programmed in PureBasic which is theoretically cross platform, but only with a lot of adaptions to every platform. I've done once a Linux version, but never a MAC version.
PureBasic is not free, so I never released the source code.
Propterminal for Prop1 is available since years. It was made before we had PST. The main purpose is the emulation of TV_Text, Keyboard and Mouse via a PC, so you don't need the physical devices to test Spin code. Later I added a "normal Terminal" mode.
It is programmed in PureBasic which is theoretically cross platform, but only with a lot of adaptions to every platform. I've done once a Linux version, but never a MAC version.
PureBasic is not free, so I never released the source code.
Andy
Okay, thanks. Maybe I'll try writing a simple terminal program in Qt at some point.
Andy: Maybe David would be interested to look at the source of the terminal section of your code.
I would certainly be interested, but not now. It would probably be possible to put it into VB6 and then we could easily add scroll bars, etc.
Just a thought.
BTW Do you use VB6?
Just an update..
This code simulates my debugger taking control to dum hub and cog memory. The format is xxxxx.<cr> for displaying hub and xxx,<cr> for displaying cog - a single line is displayed (4 longs).
Next is to make this a single call to my debugger from the user program. Works on DE0 because only cog 0 is used. Return to the user program by typing <esc><cr>.
After this, modify hub and cog by xxxxx: xx xx ....<cr> and xxx; xx xx ...<cr> LSD_035.spin
In debug mode, you can examine HUB and COG memory as follows...
{addr}.<cr> = dump hub address
{addr},<cr> = dump cog address
<cr> = repeat last command {addr} is incremented
<esc><cr> = return to users cog program
The demonstration program displays various values and dumps, then enters DEBUG mode and waits for user input as shown above.
<esc><cr> returns to the user cog program and displays a message using TXSTRING and then returns to the ROM Monitor.
The concept behind this debugger is that you can stall the user cog program and execute a limited monitor using LMM and then return to the user cog program.
Currently the cog footprint has not been optimised, and neither has the LMM (hub) code.
I have included the .obj file for downloading with p2load "p2load -v -s lsd_043.obj -h". Note rename the .obj.bin after downloading. Note2 the -t mode does not work correctly because I only send <cr> not <cr><lf> - use PST (there is a 5 sec delay to allow you to get this running).
Next addition will be to make changes to Hub & Cog memory from the debug/monitor mode.
Is this <cr> vs <cr><lf> thing the only reason you can't use the -t option of p2load or are there other problems as well? For instance, do you need the Parallax font? I guess I could get p2load to handle lines that only end in <cr>.
David:
The biggest reason is <cr> only. But also, when debugging you want to see what has gone by, so the scroll bars on PST comes in handy for looking quite a ways back. But for simple things, having an option to perform <cr><lf> when a <cr> is received (and probably ignoring any <lf>) would be a big help when all you really want is a quick test to see everything is doing what you expect. Enabling PST is the hardest because it is timing sensitive - too slow and you miss the output!
So, to answer your question, yes please - I would use it probably 95% of the time, leaving 5% when I need to see the older output in PST.
Currently I have 3 windows open:
pnut (source code and Ctl-L to compile)
dos command (type "p2" which is my bat file to p2load my obj)
PST (which has to be clicked on and enabled, hence my 5 sec delay in prop code)
The .obj code is there if you want to give it a try (plus source).
use...
p2load -b 115200 -v -s lsd_043.obj -h -t
This is what the program automatically outputs before waiting for input...
789
12
<0D>%<95>
1A2B3C4D
4D3C2B1A
4D3C2B1A
The fox was here!!
01000- 0D A2 FC 0C 53 A2 BC 80 00 A2 BC FC 0D C8 FC A0 '....S...........'
01010- 5E C6 FC 1F 37 C8 FC A0 5E C6 FC 1F 38 C8 FC A0 '^...7...^...8...'
01020- 5E C6 FC 1F 39 C8 FC A0 5E C6 FC 1F 0D C8 FC A0 '^...9...^.......'
01030- 5E C6 FC 1F 55 C8 BC A0 5E C6 FC 1F 20 CA FC A0 '^...U...^... ...'
01040- 0D C8 FC A0 5C C6 FC 1F 25 C8 FC A0 5C C6 FC 1F '....\...%...\...'
000- 0D A2 FC 0C 53 A2 BC 80 00 A2 BC FC 0D C8 FC A0 '....S...........'
004- 5E C6 FC 1F 37 C8 FC A0 5E C6 FC 1F 38 C8 FC A0 '^...7...^...8...'
008- 5E C6 FC 1F 39 C8 FC A0 5E C6 FC 1F 0D C8 FC A0 '^...9...^.......'
00C- 5E C6 FC 1F 55 C8 BC A0 5E C6 FC 1F 20 CA FC A0 '^...U...^... ...'
010- 0D C8 FC A0 5C C6 FC 1F 25 C8 FC A0 5C C6 FC 1F '....\...%...\...'
David:
The biggest reason is <cr> only. But also, when debugging you want to see what has gone by, so the scroll bars on PST comes in handy for looking quite a ways back.
Okay, I'll add PST-mode to p2load. It may have to wait until tonight though. Also, you should be able to configure your DOS window to allow you to scroll back. There is a setting that tells it how many lines of scrollback to keep. I think the default is fairly small but you can make it pretty much as big as you want.
David:
The biggest reason is <cr> only. But also, when debugging you want to see what has gone by, so the scroll bars on PST comes in handy for looking quite a ways back. But for simple things, having an option to perform <cr><lf> when a <cr> is received (and probably ignoring any <lf>) would be a big help when all you really want is a quick test to see everything is doing what you expect. Enabling PST is the hardest because it is timing sensitive - too slow and you miss the output!
So, to answer your question, yes please - I would use it probably 95% of the time, leaving 5% when I need to see the older output in PST.
Currently I have 3 windows open:
pnut (source code and Ctl-L to compile)
dos command (type "p2" which is my bat file to p2load my obj)
PST (which has to be clicked on and enabled, hence my 5 sec delay in prop code)
The .obj code is there if you want to give it a try (plus source).
use...
p2load -b 115200 -v -s lsd_043.obj -h -t
This is what the program automatically outputs before waiting for input...
789
12
<0D>%<95>
1A2B3C4D
4D3C2B1A
4D3C2B1A
The fox was here!!
01000- 0D A2 FC 0C 53 A2 BC 80 00 A2 BC FC 0D C8 FC A0 '....S...........'
01010- 5E C6 FC 1F 37 C8 FC A0 5E C6 FC 1F 38 C8 FC A0 '^...7...^...8...'
01020- 5E C6 FC 1F 39 C8 FC A0 5E C6 FC 1F 0D C8 FC A0 '^...9...^.......'
01030- 5E C6 FC 1F 55 C8 BC A0 5E C6 FC 1F 20 CA FC A0 '^...U...^... ...'
01040- 0D C8 FC A0 5C C6 FC 1F 25 C8 FC A0 5C C6 FC 1F '....\...%...\...'
000- 0D A2 FC 0C 53 A2 BC 80 00 A2 BC FC 0D C8 FC A0 '....S...........'
004- 5E C6 FC 1F 37 C8 FC A0 5E C6 FC 1F 38 C8 FC A0 '^...7...^...8...'
008- 5E C6 FC 1F 39 C8 FC A0 5E C6 FC 1F 0D C8 FC A0 '^...9...^.......'
00C- 5E C6 FC 1F 55 C8 BC A0 5E C6 FC 1F 20 CA FC A0 '^...U...^... ...'
010- 0D C8 FC A0 5C C6 FC 1F 25 C8 FC A0 5C C6 FC 1F '....\...%...\...'
Okay, I'll add PST-mode to p2load. It may have to wait until tonight though. Also, you should be able to configure your DOS window to allow you to scroll back. There is a setting that tells it how many lines of scrollback to keep. I think the default is fairly small but you can make it pretty much as big as you want.
I had a little extra time this morning so I added a -T option to enter a PST-compatible terminal mode where \r is translated to \r\n on output. Use this instead of -t if you want PST-like behavior on \r. The new version is posted to the top of the p2load thread.
I had a little extra time this morning so I added a -T option to enter a PST-compatible terminal mode where \r is translated to \r\n on output. Use this instead of -t if you want PST-like behavior on \r. The new version is posted to the top of the p2load thread.
You're welcome! Did you also see my note about scrolling back in a DOS window? Just edit the properties of your DOS command shortcut to increase the number of lines remembered.
Sapieha,
I am not sure what you mean?
Only if the user code uses a driver that can be modified can you insert the <lf> after a <cr>. I do this as an option in my PropOS, but there I have control of the code and driver.
Sapieha,
I am not sure what you mean?
Only if the user code uses a driver that can be modified can you insert the <lf> after a <cr>. I do this as an option in my PropOS, but there I have control of the code and driver.
For those following this thread and who want to try it out with p2load (now works great with the new -T (terminal) mode)... p2load v0.006
Thanks David!
In a DOS window (run cmd)
p2load -b 115200 -v -s lsd_043.obj -h -T
Note <esc> goes back to the dos prompt (it is intercepted) rather than to the user (demo) program. I need to set another ctl char for this.
My main need for this debugger is to get the spin interpreter running (using my faster P1 version as the base).
I have a DE0, hence my need for the debugger code to use LMM hub code in the same cog. Anyway, this makes
sense to just make a call to the debugger when required.
I am also thinking about where to take this debugger next...
Obviously, need to get the modify hub/cog memory working.
Perhaps install a limited number of breakpoints?
Perhaps single step or trace 'n' instructions?
(I did this in my P1 zero footprint debugger using another cog in spin to do the control)
For those following this thread and who want to try it out with p2load (now works great with the new -T (terminal) mode)... p2load v0.006
Thanks David!
In a DOS window (run cmd)
p2load -b 115200 -v -s lsd_044.obj -h -T
Note <esc> goes back to the dos prompt (it is intercepted) rather than to the user (demo) program. I need to set another ctl char for this.
Comments
I am going to take a better look at the functions of chips monitor. Just some of the basics may be useful, particularly the xxxx.xxxx command to examine memory (DUMP mode).
And DUMP from the Cog will be neat.
Postedit:
Just been looking thru Chip's P2 ROM Monitor program and noticed a quirk in that his Tx routine can send 2 characters in "x". This would also work for 3 chars (but not 4). I added an AND x,#$FF to ensure the user didn't have bits b31..8 erroneously set. I am going to think more about this, as it saves a bit of code.
Also saw an interesting way of using a multiple entry point to accumulate a value. The usual way to do this requires the value to be zeroed first, then a set of add x,#1 intructions to accumulate in x. Chip's way (see cmd_byte/word/long labels) does not require this, by using the Z flag which is set Z=0 on entry.
Postedit 2:
Current v0.20 hub usage is <1KB (~$3A0) plus the 16 longs (loaded into user cog) and any user calls.
LMM_SerialDebugger_022.spin
I have a other few things to do for a few days, so in the meantime...
The user can use Rx (reads a character from the serial port - this is half duplex and no buffers, so it waits for a character) to read a character and do whatever. In my demo, I use <esc> to reload the ROM Monitor (which required a <space> to autobaud).
This is what I think is next...
- New call RXSTRING
- Receives a serial stream of characters to a hub buffer.
- The receive string is terminated by a <cr> which optionally can be copied to the buffer.
- The hub buffer will be terminated by a <nul> = $0.
- New call MONITOR to invoke my minimal version of the ROM Monitor (in LMM) so that at the end, the user can return to the user cog program. So this becomes similar to the ROM Monitor, but the users pasm program is stalled in the background.
- User cog and hub data can then be viewed/changed.
- Control can then be returned to the users program by <esc>
- These are the commands I am thinking of adding to my monitor section (subset of the ROM Monitor commands)
- View (single address, <space> displays the next line) - can view both hub and cog addresses
- {addr.}
- Enter (single address, followed by data pairs)
- {addr: {dat{ dat}}
What are your thoughts/comments ???It can now dump both cog and hub addresses, and receive characters.There is still some code tidyup to do to reduce the cog footprint.
Included is a demo pasm program that calls these features.
There is a problem that I think may be in pnut.exe. It seems that pnut can only compile up to 2KB because hub is only loaded up to $165F followed by 32 bytes I think is inserted by pnut.
LMM_SerialDebugger_025.spin
It inserts 0's to $E80 and fillers to position the HUB LMM code at $1800+
Use pnut to compile and "p2load -v xxxx.obj -s"
Note the output format I am currently using does not work properly with p2load terminal mode, so I have resorted to PST (think it may be me using <cr> w/o <lf>).
LMM_SerialDebugger_030.spin
Why You don't have Print / Collect routines for Decimal and Binary IN / OUT ?
Sapieha: I may add decimal and binary later. Then it could be used as a general purpose I/O in the OS.
But for now, I am interested in being able to debug an operational P2 program. So I need to add readstring, followed by the ability of the debugger to use the readstring to display/modify cog and hub ram under user (terminal) control in addition to program control. I also want to add trace/singlestep control, like I did in my P1 zero footprint debugger.
I need all this to help me debug my version of the spin interpreter.
Would you be able to make an option to do this too?
I see you have rows and columns specified in your ini file. Can I increase the rows/lines? The ability to scroll back in PST is quite an advantage at times.
I uploaded version 0.2 of Prop2Terminal to the sticky thread (to the same post as before, so it is easy to find).
This version allows to specify the target hubaddress for *.OBJ files, so they can now be loaded to every address in hub. If you specify an address < $E80 the bytes until $E80 are skipped, so the equivalent to -s of P2load ist to specify 0 as target address.
You can increase the cols and rows parameter in the .ini file, but you just get a bigger window, no scrollbars.
Andy
Are you using the rom monitor to download your code? You may have seen Sapieha is looking for this mode (with using the input file in the rom monitor format as can be used by Ctl-L in the monitor and copy/paste/save).
Hi Andy,
I'm afraid I haven't been following Prop2Terminal. Is this a cross-platform terminal program? What is it written in? I'm wondering if I can combine it with p2load to make a GUI version of the loader with a good terminal emulator built in?
Thanks,
David
It is programmed in PureBasic which is theoretically cross platform, but only with a lot of adaptions to every platform. I've done once a Linux version, but never a MAC version.
PureBasic is not free, so I never released the source code.
Andy
I would certainly be interested, but not now. It would probably be possible to put it into VB6 and then we could easily add scroll bars, etc.
Just a thought.
BTW Do you use VB6?
This code simulates my debugger taking control to dum hub and cog memory. The format is xxxxx.<cr> for displaying hub and xxx,<cr> for displaying cog - a single line is displayed (4 longs).
Next is to make this a single call to my debugger from the user program. Works on DE0 because only cog 0 is used. Return to the user program by typing <esc><cr>.
After this, modify hub and cog by xxxxx: xx xx ....<cr> and xxx; xx xx ...<cr>
LSD_035.spin
In debug mode, you can examine HUB and COG memory as follows...
{addr}.<cr> = dump hub address
{addr},<cr> = dump cog address
<cr> = repeat last command {addr} is incremented
<esc><cr> = return to users cog program
The demonstration program displays various values and dumps, then enters DEBUG mode and waits for user input as shown above.
<esc><cr> returns to the user cog program and displays a message using TXSTRING and then returns to the ROM Monitor.
The concept behind this debugger is that you can stall the user cog program and execute a limited monitor using LMM and then return to the user cog program.
Currently the cog footprint has not been optimised, and neither has the LMM (hub) code.
LSD_043.spin
LSD_043.obj.bin
I have included the .obj file for downloading with p2load "p2load -v -s lsd_043.obj -h". Note rename the .obj.bin after downloading. Note2 the -t mode does not work correctly because I only send <cr> not <cr><lf> - use PST (there is a 5 sec delay to allow you to get this running).
Next addition will be to make changes to Hub & Cog memory from the debug/monitor mode.
The biggest reason is <cr> only. But also, when debugging you want to see what has gone by, so the scroll bars on PST comes in handy for looking quite a ways back. But for simple things, having an option to perform <cr><lf> when a <cr> is received (and probably ignoring any <lf>) would be a big help when all you really want is a quick test to see everything is doing what you expect. Enabling PST is the hardest because it is timing sensitive - too slow and you miss the output!
So, to answer your question, yes please - I would use it probably 95% of the time, leaving 5% when I need to see the older output in PST.
Currently I have 3 windows open:
pnut (source code and Ctl-L to compile)
dos command (type "p2" which is my bat file to p2load my obj)
PST (which has to be clicked on and enabled, hence my 5 sec delay in prop code)
The .obj code is there if you want to give it a try (plus source).
use...
p2load -b 115200 -v -s lsd_043.obj -h -t
This is what the program automatically outputs before waiting for input...
How I can add LF to USER code
I am not sure what you mean?
Only if the user code uses a driver that can be modified can you insert the <lf> after a <cr>. I do this as an option in my PropOS, but there I have control of the code and driver.
Now that David Give us -T flag ---- So You can forget my question
Thanks David!
In a DOS window (run cmd)
p2load -b 115200 -v -s lsd_043.obj -h -T
Note <esc> goes back to the dos prompt (it is intercepted) rather than to the user (demo) program. I need to set another ctl char for this.
I have a DE0, hence my need for the debugger code to use LMM hub code in the same cog. Anyway, this makes
sense to just make a call to the debugger when required.
I am also thinking about where to take this debugger next...
Obviously, need to get the modify hub/cog memory working.
Perhaps install a limited number of breakpoints?
Perhaps single step or trace 'n' instructions?
(I did this in my P1 zero footprint debugger using another cog in spin to do the control)
Any other suggestions?
I don't see that one posted --- last one are 043