I now have sampled all info on command's that "LSD_049.spin" have.
And merged them in my spin file.
Can You in future update that in Yours revisions?. And even look if I dont have any error in it.
'' +--------------------------------------------------------------------------+
'' | Cluso's LMM_SerialDebugger for Propeller II (DE0-Nano Emulator) v0.xx |
'' +--------------------------------------------------------------------------+
'' | Authors: (c)2013 "Cluso99" (Ray Rodrick) |
'' | License: MIT License - See end of file for terms of use |
'' +--------------------------------------------------------------------------+
'' | Acknowledgements: Bill Henning - original LMM methodology |
'' | Andy (Ariba) - help with LMM call format |
'' | Chip Gracey - original P2 ROM Monitor |
'' | Chip & Parallax - P2 and DE0 emulation & expansion pcb|
'' +--------------------------------------------------------------------------+
'' p2load -b 115200 -v -s LSD_049.obj -h -T
''
Direct DEBUG commands... prompt ">"
---------------------
xxx,<cr> Display (DUMP) COG longs
<cr> Display (repeat DUMP) next 4 COG longs <cr> = repeat last command {addr} is incremented
xxxxxx.<cr> Display (DUMP) HUB longs
<cr> Display (repeat DUMP) next 4 HUB longs <cr> = repeat last command {addr} is incremented
Dump code now also displays hex and hex reversed in addition to the instruction format.
Works for both cog and hub.
xxx'<cr> will display the cog address (instruction) code, and
xxxxxx"<cr> will display the hub address (instruction) code.
A <cr> will display the next address.
Note leading zeros may be omitted in the addresses.
aaa$DDDDDDDD<cr> Input and store long "dddddddd" into COG address "aaa"
aaaaa#DDDDDDDD<cr> Input and store long "dddddddd" into HUB address "aaaaa"
xxx!<cr> resumes (RUN) user code at cog address xxx (i.e. goto). xxx may be omitted for addr=0.
Ctl-Z<cr> now passes control to the Rom Monitor (was <esc> but that conflicts with p2load Terminal mode)
''
Can You free ' and " characters by replace them with ( and [.
And made with ' and " Input string in COG and HUB in same manner as Input LONG values?
You have Input string --- But it need every time I will use it write some moving routines that it is now AS next command destroy that.
But I not have so much COG space now for that. So it can be handy to diverse test's.
My current decoding method limited the special chars $21-$2F. I have to change this, but am thinking that the whole command structure needs a rethink. An alpha char G-Z makesmore sense and possibly as the first char in the sequence/string.
Something more like the old micro monitors seems more attractive. What do you think?
For Input strings ' and " make correct sense ---- As them are used even In languages to mark that it is string.
on other command's.
R ---> RUN
M --> Monitor.
d ---> Dump COG
D --> Dump HUB
h----> Input and store long "dddddddd" into COG address "aaa"
H----> Input and store long "dddddddd" into HUB address "aaa"
'
> Input and store string "This String" into COG address "aaa"
" ----> Input and store string "This String" into HUB address "aaa"
b ---> Show COG address (instruction) code
B ---> Show HUB address (instruction) code
My current decoding method limited the special chars $21-$2F. I have to change this, but am thinking that the whole command structure needs a rethink. An alpha char G-Z makesmore sense and possibly as the first char in the sequence/string.
Something more like the old micro monitors seems more attractive. What do you think?
I made some changes that maybe can be of interest.
1. Moved Strings to END of HUB code. That spare many Long's in COG
Part 1
' display hub string
mov lmm_y, #_TXSTRING '\ set string mode
mov lmm_x, MadeByL '| set string hub address
call #LmmFun wz,wc '/
jmp #donestring
''
MadeByL long @MadeBy ''Addres to Yours "Cluso's P2 Debugger v0.49",$0D,$0D,0
RMonitorL long @RMonitor ''Addres to Yours "To Rom Monitor - hit <space>",$0D,0
''::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
QHOW_txt long @QHOW_txt_p ' the HUB address of string1
''::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Bit_txt long @Bit_txt_p ' the HUB address of string1
''
Part 2
' 'FRET SP-- ' \
sub lmm_sp, #4 ' | SP--
rdlong lmm_w, lmm_sp ' | POP PC...
add lmm_w, #8 ' | ...PC++2... (reposn retn adr -skips rdlong/long)
mov lmm_pc, lmm_w ' / ...RET
'------------------------------------------------------------------------------
MadeBy byte "Cluso's P2 Debugger v0.49",$0D,$0D,0 ' this will be displayed from hub
'MadeByL long @MadeBy ''Need be in COG ' the hub address of string1
RMonitor byte "To Rom Monitor - hit <space>",$0D,0
'RMonitorL long @RMonitor ''Need be in COG
''00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Bit_txt_p Byte " Instr ZCR I CCCC Des Src 0 1 2 3 3 2 1 0",$0d,0
'' 011- 100001 110 1 1100 1D2 03A - 0CFF1E0D 0D1EFF0C
'Bit_txt long @Bit_txt_p ''Need be in COG ' the HUB address of string1
QHOW_txt_p Byte $0D," HOW",$0D,0,0 ',$0D -->not used
'QHOW_txt long @QHOW_txt_p ''Need be in COG ' the HUB address of string1
''
''::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
''==================================================================================================
byte "*"[16-(($ & 3)*4)] ' fill to next quad long
''=======[ Hub LMM Buffers ]===================================================
byte "=== HUB STACK ==" ' 16 byte identifier (maybe removed to save space)
_hub_buf byte 0[128] ' hub buffer (maybe reduced to save space)
_hub_buf3 byte 0[64] ' hub buffer3 (maybe reduced to save space)
_hub_stack long 0[32] ' hub stack (maybe reduced to save space)
byte "=== HUB END ===" ' 16 byte identifier (maybe removed to save space)
''==================================================================================================
''
.
.
2. Edited this routine and added some code in USER area
Part 1
' display the instruction code from cog/hub
''-------------
''' TX: <cr>
mov lmm_x, #$0D '\ <cr>
call #LmmTx wz,wc '/ call LmmTx routine (saves and restores Z & C flags)
' display hub string
mov lmm_y, #_TXSTRING '\ set string mode
mov lmm_x, Bit_txt '* set Bit's value info
call #LmmFun wz,wc '*
mov lmm_y, #_DUMP+_COG+_CODE ' set dump cog code
mov lmm_x, D7 ''#:InstDebug ' set hub/cog address
call #LmmFun wz,wc
mov count, D6 ' do n lines
:loop3 call #LmmFun wz,wc
djnz count,#:loop3
D6 Long $0
D7 Long $0
''
.
.
.
Part 2 ...... Bloks that are betwen ''00000000000-- and ''11111111111- NEED be placed at Start and end of code
............. That anyone will show
USER_code
''
''************ Start of MAIN code **************************
''
DAT
''--- $01000 ------------------------------------------------------------------------------------
ORG 0
''00000000000------------------------ To place before Instruction's to Show ---------------------
InstDebug MOV D7,InstD
'' MOV _DLines,D6 '' Debuged Lines to Show
MOV D6,_DLines
InstD LONG $+1 '' Runs AS NOP
''00000000000------------------------------------------------------------------------------------
entry
'the following is a 0.5 sec delay mechanism only (allows PST to start)
getcnt wait
add wait,delta0
waitcnt wait,0
add D5,delta0
add D5,delta0
''
jmp #ENDS
''
START org $
''
''11111111111----------------------- To place after last Instruction to Show ---------------------
_DLines LONG $-3
''11111111111------------------------------------------------------------------------------------
Sapieha: Just read your posts so have not had time yet to look at your changes.
Note though that the demo running in user cog can be completely removed. It is just an example. Only the lmm_.... section is required in user cog, and this has to be refined to reduce the number of longs required. For now, each time I need a new variable in cog, I just add it here. Later I will use the push/pop to save the variables without requiring them in cog so that will reduce the footprint.
I also have various footprint longs so I can easily see where the code is. These are not required either. There is a lotI can do to free up hub usage, but for now I am more interested in getting the maximum flexibility in the code. Later I will revisit it to reduce the footprints in both cog and hub.
I need to check and see if pnut can use objects because I could then split the code. However, I am also wanting to try GAS, as that should permit me to use macros for the push/pop/fcall code.
Sapieha: Just read your posts so have not had time yet to look at your changes.
Note though that the demo running in user cog can be completely removed. It is just an example. Only the lmm_.... section is required in user cog, and this has to be refined to reduce the number of longs required. For now, each time I need a new variable in cog, I just add it here. Later I will use the push/pop to save the variables without requiring them in cog so that will reduce the footprint.
I also have various footprint longs so I can easily see where the code is. These are not required either. There is a lotI can do to free up hub usage, but for now I am more interested in getting the maximum flexibility in the code. Later I will revisit it to reduce the footprints in both cog and hub.
I need to check and see if pnut can use objects because I could then split the code. However, I am also wanting to try GAS, as that should permit me to use macros for the push/pop/fcall code.
Next installment includes some of Sapieha's suggestions and ideas...
The dump code now includes ascii output as well.
A heading string in hub is available for the user to display using TXSTRING.
Debug mode now displays a prompt "*".
In Debug mode,
Ctl-Q quits and starts the Rom Monitor.
Ctl-Z returns to the user program.
RxString has an extra option _PROMPT to display prompt character(s) in lmm_x.
_MONITOR is a new call that starts the Rom Monitor (reduces the cog footprint).
One thing --- If it was possible RxString have one more variable on entry that change STRING Input position.
mov lmm_y, #_RXSTRING+_ECHO '\ set rxstring mode: options _ECHO
mov lmm_x,????? '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
call #LmmFun wz,wc '| call LmmFun routine (saves and restores Z & C flags)
???? mov ?????, yyyyy '/ Bytes returned
I USE Stack intensively --- And don't have place to LMM for that !!!
.
'' RR20130417 0.51 Ctl-Z returns to user cog program
'' Ctl-Q quits & goto rom monitor
''[SIZE=3] [COLOR=#ff0000][B]To Do: Use stack to reduce long requirements in cog[/B][/COLOR][/SIZE]
.
My thinking are --- Made RXSTRING so it can take 2 parameters.
First one are Yours standard one "lmm_y, #_RXSTRING+_ECHO".
Second "lmm_x,?????" -- where "?????" are HUB address that that strings will be placed.
Return value from RXSTRING " ?????, yyyyy"
"?????" = My temp variable to hold character counter.
"yyyyy" = "lmm_x" character counter -1 (0 position) returned from RXSTRING
with that I can made routine to input XX = Lines of text (Basic) code that can be placed in HUB at any place.
And no need return to debugger before all text are colected
I have already next clear routine to save and reload that to FLASH for use with tests
One thing --- If it was possible RxString have one more variable on entry that change STRING Input position.
mov lmm_y, #_RXSTRING+_ECHO '\ set rxstring mode: options _ECHO
mov lmm_x,????? '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
call #LmmFun wz,wc '| call LmmFun routine (saves and restores Z & C flags)
mov ?????, yyyyy '/ Bytes returned
What I did with RxString was to use lmm_x for holding the prompt char(s) if the _PROMPT option was used. This actually permits a prompt of up to 4 chars because it uses the Tx routine to display the prompt. These char(s) could be <cr>*>: or in fact any 1..4 characters.
What you would like is to pass a hub ptr to store the string, and a place to return the count of the number of characters entered -1. Not sure that the -1 would be useful to most, but I can see that it would be preferable to be able to pass the address ptr to a hub location to be used. Currently I don't check limits, so the hub buffer can be overflowed, or underflowed by backspacing too far - this needs to be done. So how do we ensure that the buffer is not overflowed - you would need to pass the max length of the buffer also.
Now, looking at further uses of this debugger...
Would a move/copy hub to hub be useful? It could have a string version (ie nul terminated) that could also return the length of the string.
I guess where I would like to take this is a set of useful routines plus debugger that a program can use which resides in hub and uses LMM. So ultimately, the I/O need not be serial, but could use a substitute I/O driver.
What I did with RxString was to use lmm_x for holding the prompt char(s) if the _PROMPT option was used.
This actually permits a prompt of up to 4 chars because it uses the Tx routine to display the prompt.
These char(s) could be <cr>*>: or in fact any 1..4 characters.
1. I don't say You shall change that.
That function very good
But what I ask is if You can use "lmm_x" else any other "lmm_?????" to pass that ADDRESS to it on entry
... mov . lmm_y, #_RXSTRING+_ECHO .... '\ set rxstring mode: options _ECHO
... mov . lmm_x,????? ................ '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
... call .#LmmFun wz,wc .............. '| call LmmFun routine (saves and restores Z & C flags)
... mov . ?????, yyyyy ................ '/ Bytes returned
What you would like is to pass a hub ptr to store the string, and a place to return the count of the
number of characters entered -1. Not sure that the -1 would be useful to most, but I can see that it would
be preferable to be able to pass the address ptr to a hub location to be used. Currently I don't check limits,
so the hub buffer can be overflowed, or underflowed by backspacing too far - this needs to be done.
So how do we ensure that the buffer is not overflowed - you would need to pass the max length of the buffer also.
Would a move/copy hub to hub be useful? It could have a string version (ie nul terminated)
that could also return the length of the string.
3. Can be very usable
REM Test_Text
REM 026E0.
30 Print "to destroy ",#1,K," Klingons in 30 stardates."
35 GOSUB 160:C=0,H=K
50 I=1:IF N FOR J=1 TO N:GOSUB 165:NEXT J
REM That's all.
3D 3D 3D 20 48 55 42 20 20 45 4E 44 20 3D 3D 3D '=== HUB END ==='
00 00 00 00 FF FF FF FF FF FF FF FF 52 45 4D 20 '............REM '
54 65 73 74 5F 54 65 78 74 0D 0A 52 45 4D 20 30 'Test_Text..REM 0'
32 36 45 30 2E 0D 0A 33 30 20 50 72 69 6E 74 20 '26E0...30 Print '
22 74 6F 20 64 65 73 74 72 6F 79 20 22 2C 23 31 '"to destroy ",#1'
2C 4B 2C 22 20 4B 6C 69 6E 67 6F 6E 73 20 69 6E ',K," Klingons in'
20 33 30 20 73 74 61 72 64 61 74 65 73 2E 22 0D ' 30 stardates.".'
0A 33 35 20 47 4F 53 55 42 20 31 36 30 3A 43 3D '.35 GOSUB 160:C='
30 2C 48 3D 4B 0D 0A 35 30 20 49 3D 31 3A 49 46 '0,H=K..50 I=1:IF'
20 4E 20 46 4F 52 20 4A 3D 31 20 54 4F 20 4E 3A ' N FOR J=1 TO N:'
47 4F 53 55 42 20 31 36 35 3A 4E 45 58 54 20 4A 'GOSUB 165:NEXT J'
0D 0A 52 45 4D 20 54 68 61 74 27 73 20 61 6C 6C '..REM That's all'
2E 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.......|..| number of characters entered
.......| number of characters entered -1.
How I will use it
mov . lmm_!!,03000 ....... ????? - My buffer position
mov . ????? ,03000 ................ '/ Next line position
yyyyy ................ '/ Bytes returned
1-80 in one line if more -->- ERROR MAYBE cut to 80 else return in bytes counter -1
mov . ?????, yyyyy ................ '/ Bytes returned
Input
......... mov . MyTemp,X .....................' Lines to return
......... mov . lmm_y, #_RXSTRING+_ECHO ..... '\ set rxstring mode: options _ECHO
loop..... mov . lmm_!!,????? ................ '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
........ call .#LmmFun wz,wc ................ '| call LmmFun routine (saves and restores Z & C flags)
......... cmp . yyyyy,#1 .................... '/ If Bytes =1 returned (Only <cr> entered END Loop
......... add . ?????, yyyyy ................ '/ ADD Bytes returned NEXT line position
......... mov . lmm_!!, yyyyy ............... '/ Bytes returned
........ djnz . MyTemp,#loop ......... Loop for next line
Sapieha:
Yes, it seems that a 3rd parameter is in order. That would therefore usually be for a hub pointer.
RXSTRING
'on input
lmm_x = char(s) if _PROMPT option
lmm_y = #_RXSTRING [+_PROMPT] [+_BUFPTR] [+_ECHO]
lmm_z = hubptr if _BUFPTR option
'on return
lmm_x = no of chars in string
lmm_y = -same-
lmm_z = hubptr to string (either user supplied on entry, or internal buffer)
Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too.
"Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too."
1. 80 characters is sufficient. <cr> need be always included and line terminated with $0. but "lmm_x = no of chars in string" need point to $0D as it is only entire TEXT that need be terminated with $0.
It is why I need "no of chars in string" that if I input next line I add it to my Variable and place that in "lmm_z = hubptr if _BUFPTR option" on next round in LOOP without return to debugger.
That give possibility to use CUT (from and editor) and PASTE .to terminal window any text that be correctly placed IN buffer with lines separated with $0D
'on return
lmm_x = no of chars in string else -1 if error (to many characters)
Sapieha:
Yes, it seems that a 3rd parameter is in order. That would therefore usually be for a hub pointer.
RXSTRING
'on input
lmm_x = char(s) if _PROMPT option
lmm_y = #_RXSTRING [+_PROMPT] [+_BUFPTR]
lmm_z = hubptr if _BUFPTR option
'on return
lmm_x = no of chars in string
lmm_y = -same-
lmm_z = hubptr to string (either user supplied on entry, or internal buffer)
Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too.
"Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too."
1. 80 characters is sufficient. <cr> need be always included and line terminated with $0. but "lmm_x = no of chars in string" need point to $0D as it is only entire TEXT that need be terminated with $0.
Yes, the count includes the <cr> but not the <nul>.
It is why I need "no of chars in string" that if I input next line I add it to my Variable and place that in "lmm_z = hubptr if _BUFPTR option" on next round in LOOP without return to debugger.
That give possibility to use CUT (from and editor) and PASTE .to terminal window any text that be correctly placed IN buffer with lines separated with $0D
Yes I understand.
'on return
lmm_x = no of chars in string else -1 if error (to many characters)
[/quote]
Do you think I should return with -1 rather than just wait for backspace to correct the input?
I have been thinking about the Dump Code call from my debugger (unsure about when called from the user program)...
Do not do <cr> once the line is displayed and wait for input which can be...
<cr> = go dump next location
"......<cr> inputs a string of text characters and stores as bytes at from the first address (variable length, not checked)
'xxxxxxxx<cr> inputs a long at the location (xxxxxxxx can be 1-8 hex digits)
`xx xx xx xx xx xx xx xx...<cr> inputs a string of hex bytes and stores as bytes from the first address (variable length, not checked) (' is backquote)
All the above may be interspersed on the one line.
any other leading character is interpreted as a new command, and will cause a <cr> followed by the display (echo) of that character.
It is possible to modify that INPUT routines that can use more that one HEX value ---- Separated by ","
aaa$DDDDDDDD<cr> Input and store long "dddddddd" into COG address "aaa"
aaaaa#DDDDDDDD<cr> Input and store long "dddddddd" into HUB address "aaaaa"
.
To.
aaa$DDDDDDDD,DDDDDDDD,DDDDDDDD,DDDDDDDD,DD DD DD DD<cr> Input and store long "dddddddd" into COG address "aaa"
aaaaa#DDDDDDDD,DDDDDDDD,DDDDDDDD,DDDDDDDD,DD DD DD DD<cr> Input and store long "dddddddd" into HUB address "aaaaa"
.That need be to decoded as one LONG ----> DD DD DD DD
Thinking further, any address >$1FF is hub and anything <= is cog. There is no reason we need to look at lower hub rom because this can be done with the rom monitor, and it is published anyway. This may simplify things a bit.
For the "goto" commands, maybe...
xxxG<cr>
where G can also be lower case
xxx if omitted, is a normal return to the user code
xxx is otherwise 1-3 hex address in cog to goto.
So 0G<cr> is effectively a restart without initialising any cog registers/variables.
Thinking further, any address >$1FF is hub and anything <= is cog. There is no reason we need to look at lower hub rom because this can be done with the rom monitor, and it is published anyway. This may simplify things a bit.
For the "goto" commands, maybe...
xxxG<cr>
where G can also be lower case
xxx if omitted, is a normal return to the user code
xxx is otherwise 1-3 hex address in cog to goto.
So 0G<cr> is effectively a restart without initialising any cog registers/variables.
Any address $200+ has to be hub, and any address <$200 has to be cog. Therefore there is really no need to use a different command.
For inputting hex values, 1 or 2 digits should be byte, 3 or 4 digits should be word and 5-8 digits should be longs. This therefore takes care of endian issues (I think). Any number of bytes/words/longs can be strung on a line with spaces between. There is no need for a leading zero. Strings could be intermixed using double quotes to surround the text.
For initialising/loading a cog we could use the G command as follows:
xxxxxGpppppppp c<cr>
where pppppppp is the long parameter passed to the cog and c is the cogid (if omitted, it is the current cog)
G<cr> returns to the user program
xxxG<cr> goes to the user program at cog address xxx (0G<cr> does a restart without initialisation)
Commands can be upper/lower case alpha G-Z & g-z. (A-F & a-f are reserved for hex values)
Command V for copy/fill (ie V for paste)
xxxxxVsssss llll<cr> copies from sssss to xxxxx, length = llll (length in bytes for hub, longs for cog)
xxxxxV$zzzzzzzz llll<cr> fills xxxxx with byte/word/long zzzzzzzz for length = llll. If length omitted, just one byte/word/long
xxxxxV"the fox" $0D $00<cr> copies a string to xxxxx
Could you post an example of what you want to paste from pnut?
M could be for examining (dumping and optionally changing) memory...
xxxxxM[zzzzz]<cr> displays memory (new instruction format) where xxxxx is the first address and zzzzz is an optional last address.
Comments
THANKS
Thanks for all additions.
One Question?
It is possible to add PROMPT > else like on input line ?. So any know if it hangs else Wait for next input !
Great suggestion. But I added it as an option _PROMPT to _RXSTRING.
LSD_049.spin
Nice --- And work as wanted !!!
Thanks
I now have sampled all info on command's that "LSD_049.spin" have.
And merged them in my spin file.
Can You in future update that in Yours revisions?. And even look if I dont have any error in it.
New Question ?
Can You free ' and " characters by replace them with ( and [.
And made with ' and " Input string in COG and HUB in same manner as Input LONG values?
You have Input string --- But it need every time I will use it write some moving routines that it is now AS next command destroy that.
But I not have so much COG space now for that. So it can be handy to diverse test's.
Thanks
Something more like the old micro monitors seems more attractive. What do you think?
For Input strings ' and " make correct sense ---- As them are used even In languages to mark that it is string.
on other command's.
R ---> RUN
M --> Monitor.
d ---> Dump COG
D --> Dump HUB
h----> Input and store long "dddddddd" into COG address "aaa"
H----> Input and store long "dddddddd" into HUB address "aaa"
'
> Input and store string "This String" into COG address "aaa"
" ----> Input and store string "This String" into HUB address "aaa"
b ---> Show COG address (instruction) code
B ---> Show HUB address (instruction) code
It Is How I see it.
Thanks
How much work it is to modify Instruction showing to that.
I made some changes that maybe can be of interest.
1. Moved Strings to END of HUB code. That spare many Long's in COG
Part 1
Part 2
.
.
2. Edited this routine and added some code in USER area
Part 1
.
.
.
Part 2 ...... Bloks that are betwen ''00000000000-- and ''11111111111- NEED be placed at Start and end of code
............. That anyone will show
Note though that the demo running in user cog can be completely removed. It is just an example. Only the lmm_.... section is required in user cog, and this has to be refined to reduce the number of longs required. For now, each time I need a new variable in cog, I just add it here. Later I will use the push/pop to save the variables without requiring them in cog so that will reduce the footprint.
I also have various footprint longs so I can easily see where the code is. These are not required either. There is a lotI can do to free up hub usage, but for now I am more interested in getting the maximum flexibility in the code. Later I will revisit it to reduce the footprints in both cog and hub.
I need to check and see if pnut can use objects because I could then split the code. However, I am also wanting to try GAS, as that should permit me to use macros for the push/pop/fcall code.
Thanks for explanation.
Before You do that --- Made if You can String's Input.
I will never use GAS --- So for me it was not good news
The dump code now includes ascii output as well.
A heading string in hub is available for the user to display using TXSTRING.
Debug mode now displays a prompt "*".
In Debug mode,
Ctl-Q quits and starts the Rom Monitor.
Ctl-Z returns to the user program.
RxString has an extra option _PROMPT to display prompt character(s) in lmm_x.
_MONITOR is a new call that starts the Rom Monitor (reduces the cog footprint).
There is more user sample code included.
LSD_051.spin
Nice additions.
More that I wanted
One thing --- If it was possible RxString have one more variable on entry that change STRING Input position.
Thanks
Can You wait with that? else have 2 Versions.
I USE Stack intensively --- And don't have place to LMM for that !!!
.
I don't intend to use the clut. This refers to my hub stack where I will put things like lmm_y instead of lmm_mode, etc.
My thinking are --- Made RXSTRING so it can take 2 parameters.
First one are Yours standard one "lmm_y, #_RXSTRING+_ECHO".
Second "lmm_x,?????" -- where "?????" are HUB address that that strings will be placed.
Return value from RXSTRING " ?????, yyyyy"
"?????" = My temp variable to hold character counter.
"yyyyy" = "lmm_x" character counter -1 (0 position) returned from RXSTRING
with that I can made routine to input XX = Lines of text (Basic) code that can be placed in HUB at any place.
And no need return to debugger before all text are colected
I have already next clear routine to save and reload that to FLASH for use with tests
What you would like is to pass a hub ptr to store the string, and a place to return the count of the number of characters entered -1. Not sure that the -1 would be useful to most, but I can see that it would be preferable to be able to pass the address ptr to a hub location to be used. Currently I don't check limits, so the hub buffer can be overflowed, or underflowed by backspacing too far - this needs to be done. So how do we ensure that the buffer is not overflowed - you would need to pass the max length of the buffer also.
Now, looking at further uses of this debugger...
Would a move/copy hub to hub be useful? It could have a string version (ie nul terminated) that could also return the length of the string.
I guess where I would like to take this is a set of useful routines plus debugger that a program can use which resides in hub and uses LMM. So ultimately, the I/O need not be serial, but could use a substitute I/O driver.
1. I don't say You shall change that.
That function very good
But what I ask is if You can use "lmm_x" else any other "lmm_?????" to pass that ADDRESS to it on entry
... mov . lmm_y, #_RXSTRING+_ECHO .... '\ set rxstring mode: options _ECHO
... mov . lmm_x,????? ................ '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
... call .#LmmFun wz,wc .............. '| call LmmFun routine (saves and restores Z & C flags)
... mov . ?????, yyyyy ................ '/ Bytes returned
2. Look HEX dump end
3. Can be very usable
REM Test_Text
REM 026E0.
30 Print "to destroy ",#1,K," Klingons in 30 stardates."
35 GOSUB 160:C=0,H=K
50 I=1:IF N FOR J=1 TO N:GOSUB 165:NEXT J
REM That's all.
3D 3D 3D 20 48 55 42 20 20 45 4E 44 20 3D 3D 3D '=== HUB END ==='
00 00 00 00 FF FF FF FF FF FF FF FF 52 45 4D 20 '............REM '
54 65 73 74 5F 54 65 78 74 0D 0A 52 45 4D 20 30 'Test_Text..REM 0'
32 36 45 30 2E 0D 0A 33 30 20 50 72 69 6E 74 20 '26E0...30 Print '
22 74 6F 20 64 65 73 74 72 6F 79 20 22 2C 23 31 '"to destroy ",#1'
2C 4B 2C 22 20 4B 6C 69 6E 67 6F 6E 73 20 69 6E ',K," Klingons in'
20 33 30 20 73 74 61 72 64 61 74 65 73 2E 22 0D ' 30 stardates.".'
0A 33 35 20 47 4F 53 55 42 20 31 36 30 3A 43 3D '.35 GOSUB 160:C='
30 2C 48 3D 4B 0D 0A 35 30 20 49 3D 31 3A 49 46 '0,H=K..50 I=1:IF'
20 4E 20 46 4F 52 20 4A 3D 31 20 54 4F 20 4E 3A ' N FOR J=1 TO N:'
47 4F 53 55 42 20 31 36 35 3A 4E 45 58 54 20 4A 'GOSUB 165:NEXT J'
0D 0A 52 45 4D 20 54 68 61 74 27 73 20 61 6C 6C '..REM That's all'
2E 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.......|..| number of characters entered
.......| number of characters entered -1.
How I will use it
mov . lmm_!!,03000 ....... ????? - My buffer position
mov . ????? ,03000 ................ '/ Next line position
yyyyy ................ '/ Bytes returned
1-80 in one line if more -->- ERROR MAYBE cut to 80 else return in bytes counter -1
mov . ?????, yyyyy ................ '/ Bytes returned
Input
......... mov . MyTemp,X .....................' Lines to return
......... mov . lmm_y, #_RXSTRING+_ECHO ..... '\ set rxstring mode: options _ECHO
loop..... mov . lmm_!!,????? ................ '/ SET Buffer addres with address of the hub string, <nul> terminated <---- If omitted original ADDRES
........ call .#LmmFun wz,wc ................ '| call LmmFun routine (saves and restores Z & C flags)
......... cmp . yyyyy,#1 .................... '/ If Bytes =1 returned (Only <cr> entered END Loop
......... add . ?????, yyyyy ................ '/ ADD Bytes returned NEXT line position
......... mov . lmm_!!, yyyyy ............... '/ Bytes returned
........ djnz . MyTemp,#loop ......... Loop for next line
Thanks
one proposal to You. To future Versions
Yes, it seems that a 3rd parameter is in order. That would therefore usually be for a hub pointer.
RXSTRING
'on input
lmm_x = char(s) if _PROMPT option
lmm_y = #_RXSTRING [+_PROMPT] [+_BUFPTR] [+_ECHO]
lmm_z = hubptr if _BUFPTR option
'on return
lmm_x = no of chars in string
lmm_y = -same-
lmm_z = hubptr to string (either user supplied on entry, or internal buffer)
Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too.
I see You now understand me. Thanks
"Do you think 80 characters is sufficient, or should we allow 128 characters? If the user supplies a buffer, it will need to be this length including the $0 terminator and <cr> too."
1. 80 characters is sufficient. <cr> need be always included and line terminated with $0. but "lmm_x = no of chars in string" need point to $0D as it is only entire TEXT that need be terminated with $0.
It is why I need "no of chars in string" that if I input next line I add it to my Variable and place that in "lmm_z = hubptr if _BUFPTR option" on next round in LOOP without return to debugger.
That give possibility to use CUT (from and editor) and PASTE .to terminal window any text that be correctly placed IN buffer with lines separated with $0D
'on return
lmm_x = no of chars in string else -1 if error (to many characters)
[/quote]
Do you think I should return with -1 rather than just wait for backspace to correct the input?
I have been thinking about the Dump Code call from my debugger (unsure about when called from the user program)...
Do not do <cr> once the line is displayed and wait for input which can be...
<cr> = go dump next location
"......<cr> inputs a string of text characters and stores as bytes at from the first address (variable length, not checked)
'xxxxxxxx<cr> inputs a long at the location (xxxxxxxx can be 1-8 hex digits)
`xx xx xx xx xx xx xx xx...<cr> inputs a string of hex bytes and stores as bytes from the first address (variable length, not checked) (' is backquote)
All the above may be interspersed on the one line.
any other leading character is interpreted as a new command, and will cause a <cr> followed by the display (echo) of that character.
Your comments?
New Question.
It is possible to modify that INPUT routines that can use more that one HEX value ---- Separated by ","
.
To.
.That need be to decoded as one LONG ----> DD DD DD DD
01000 - 111111 111 1 1111 1FF 0A5 XXXXXXXX XXXXXXXX *`12 34 56 78 9A<cr>
would enter hex bytes 1000=$12, 1001=$34, 1002=$56, 1003=$78, 1004=$9A
01000 - 111111 111 1 1111 1FF 0A5 XXXXXXXX XXXXXXXX *'88889999 AAAABBBB<cr>
would enter hex longs 1000=$88889999 (ie reversed as 99 99 88 88), 1004=$AAAABBBB
01000 - 111111 111 1 1111 1FF 0A5 XXXXXXXX XXXXXXXX *"fox!<cr>
would enter ascii bytes 1000="f", 1001="o", 1002="x", 1003="!"
I am unsure about mixing them on the above on the one line.
For the "goto" commands, maybe...
xxxG<cr>
where G can also be lower case
xxx if omitted, is a normal return to the user code
xxx is otherwise 1-3 hex address in cog to goto.
So 0G<cr> is effectively a restart without initialising any cog registers/variables.
Looks good for me.
That look good But.
Why not use for enter Longs in same manner as them are displayed.
for enter to COG use
.............Long 1........Long 2.....Long 3..
. 100- 01 02 03 04 0004 0004 00000008<cr>
COG enter
0100- 01 02 03 04 0004 0004 00000008<cr>
HUB enter
for enter to HUB use ADDRESS Need be specified as 4 to 8 HEX values
That give possibility for CUT and PASTE from PNut
ctrl-L window option
I have be thinking more on it.
If You have possibility to test address for $E80 and bigger maybe it is possible to made it in same time --->
Starting any COG from HUB ???
0xxxG<cr> --- GoTot COG program
0xxx if omitted, is a normal return to the user code
0Exx else bigger
0Exx 0-7S<cr> --- Start from HUB COG 0-7
For inputting hex values, 1 or 2 digits should be byte, 3 or 4 digits should be word and 5-8 digits should be longs. This therefore takes care of endian issues (I think). Any number of bytes/words/longs can be strung on a line with spaces between. There is no need for a leading zero. Strings could be intermixed using double quotes to surround the text.
For initialising/loading a cog we could use the G command as follows:
xxxxxGpppppppp c<cr>
where pppppppp is the long parameter passed to the cog and c is the cogid (if omitted, it is the current cog)
G<cr> returns to the user program
xxxG<cr> goes to the user program at cog address xxx (0G<cr> does a restart without initialisation)
Commands can be upper/lower case alpha G-Z & g-z. (A-F & a-f are reserved for hex values)
Command V for copy/fill (ie V for paste)
xxxxxVsssss llll<cr> copies from sssss to xxxxx, length = llll (length in bytes for hub, longs for cog)
xxxxxV$zzzzzzzz llll<cr> fills xxxxx with byte/word/long zzzzzzzz for length = llll. If length omitted, just one byte/word/long
xxxxxV"the fox" $0D $00<cr> copies a string to xxxxx
Could you post an example of what you want to paste from pnut?
M could be for examining (dumping and optionally changing) memory...
xxxxxM[zzzzz]<cr> displays memory (new instruction format) where xxxxx is the first address and zzzzz is an optional last address.