You’re totally underestimating the complexity of such a tool… and how it must integrate with the rest of your source code and add the required code when you click and type a bit of text. Even sophisticated IDEs like Visual Studio only do the bare minimum for you, and you still have to go and edit the code manually and make it do what you really want.
The problem is, coding for a microcontroller in ASM (or very, very lightweight C!) requires code that would be considered ugly hacking in higher-level languages like C++ and Java… all variables being global, no use of classes, storing state in a couple of bits of one memory address instead of a nice set of named variables. The code for one menu item is in a few places, because its grouped by function, and it has to be that way, grouping it the other way would involve a lot of extra code.
TK has put a lot of work into generalizing things, hence the use of tables to “connect” a button’s DIN pins with a function to call if it’s pressed. So in your example of making “Select 1” do something different, here’s how you could have worked it out:
In cs_menu_io_tables.inc:
DIN_ENTRY CS_MENU_BUTTON_Sel1, 1, 7
Now do a “find in files” with your favourite text editor for the function CS_MENU_BUTTON_Sel1. There it is, in cs_benu_buttons.inc:
CS_MENU_BUTTON_Sel1
;; select button #1, set cursor to 1st position
movlw 0x00
;; rgoto CS_MENU_BUTTON_Select_Cont
CS_MENU_BUTTON_Select_Cont
;; do nothing if button has been depressed
IFSET MIOS_PARAMETER2, 0, return
;; set cursor to: CS_MENU_PAGE_OFFSET + number in WREG
addwf CS_MENU_PAGE_OFFSET, W
;; branch to the CS_MENU_Select function
goto CS_MENU_Select
[/code]
Note the commented-out "rgoto CS_MENU_BUTTON_Select_Cont", it "drops-down" into that function.
So, depending on which select button is pressed, it sets the number of the button in W register, which is then added to the current offset into the menu (you can scroll the menus, so Select 1 isn't always the first displayed menu item), and then calls CS_MENU_Select. Go have a look at that then...
In cs_menu.inc
[code]
CS\_MENU\_Select
;; if in name editing mode, branch to CS\_MENU\_Select\_NameFunc
IFSET CS\_STAT, CS\_STAT\_MODIFY\_NAME, rgoto CS\_MENU\_Select\_NameFunc
;; if in main page (CS\_MENU[7] set), branch to root menu
IFSET CS\_MENU, 7, goto CS\_MENU\_EXEC\_GoToRoot
;; store new position in CS\_MENU\_CURSOR\_POS
movwf CS\_MENU\_CURSOR\_POS
;; store cursor pos in CS\_MENU\_PARAMETER\_L
movwf CS\_MENU\_PARAMETER\_L
;; clear CS\_SELECT\_CTR (so that new message appears immediately)
clrf CS\_SELECT\_CTR
;; now request a display update so that we see the new parameter on screen
bsf CS\_STAT, CS\_STAT\_DISPLAY\_UPDATE\_REQ ; (see cs\_menu.inc)
;; clear counter so that cs\_menu\_timer.inc counts from zero and the menu entry is marked for a short time
clrf CS\_CURSOR\_CTR
;; clear "CS\_STAT\_CURSOR\_FLASH" bit (see cs\_menu.inc for the handling)
bcf CS\_STAT, CS\_STAT\_CURSOR\_FLASH
;; leave function if cursor pos \>= max entries
movf CS\_MENU\_ENTRIES, W
IFGEQ CS\_MENU\_CURSOR\_POS, ACCESS, return
;; branch to EXEC handler
;; get pointer to entry which has been selected
rcall CS\_MENU\_Hlp\_GetCursorPosEntry
;; get handler IDs
rcall CS\_MENU\_GetHandlerIDs
;; EXEC ID in MIOS\_PARAMETER2
movf MIOS\_PARAMETER2, W
rgoto CS\_MENU\_EXEC\_Handler
Oh, lots of code! But the interesting thing is, in the second line of code is:
;; if in main page (CS_MENU[7] set), branch to root menu
IFSET CS_MENU, 7, goto CS_MENU_EXEC_GoToRoot
[/code]
So the comment tells you it's testing if you're in the main page and to do something different.
So you can copy how that's done and put it in your button handler, so that Select 2 to Select 5 can work as an "alias" to SID 1 to SID 4 buttons, like I showed you.
Look at the rest of the code there... it's actually quite generalized, there's no references to exactly which menu it is showing, and there's no code there to draw the menu. This is because handling a button or encoder event happens at one time of the MIOS event loop, and writing to the display happens at another. A flag is set to get the display updated, and in that event handler, it works out what it should write to the display. Just look at how neat it is. It looks up the menu tables to work out what it should do, so the menus themselves are already generalized into separate tables elsewhere.
And here's the elsewhere, for example, see how the Filter menu is handled.
In cs_menu_tables.inc:
[code]
CS\_MENU\_ENTRY CS\_MENU\_FIL, "FIL", 0x00, PRINT\_NOP, EXEC\_MENU, R2PP2R\_NOP
One line to define the “menu” as it appears in the “root menu”… labelled “FIL”, given an ID called CS_MENU_FIL. Futher on, some code to define what’s in the filter menu:
; ==========================================================================
; The filter menu
; ==========================================================================
CS_MENU_TABLE_FIL
db (CS_MENU_TABLE_FIL_End-CS_MENU_TABLE_FIL)/CS_MENU_ENTRY_LEN, 0x00
;; Register (00=dummy) |<->| max print ix exec ix parameter transfer
CS_MENU_ENTRY CS_SID_FILTER_CHANNELS, "Chn", 0x07, PRINT_FILTER_CHN, EXEC_SELPAR, R2PP2R_FILTER_CHN
CS_MENU_ENTRY CS_SID_FILTER_CUTOFF, "Cut", 0x7f, PRINT_DEC, EXEC_SELPAR, R2PP2R_CC
CS_MENU_ENTRY CS_SID_FILTER_RESONANCE, "Res", 0x7f, PRINT_DEC, EXEC_SELPAR, R2PP2R_CC
CS_MENU_ENTRY CS_SID_SUSKEY, "KTr", 0x3f, PRINT_KTR, EXEC_SELPAR, R2PP2R_KTR
CS_MENU_ENTRY CS_SID_FILTER_MODE, "Mod", 0x07, PRINT_FILTER_MOD, EXEC_SELPAR, R2PP2R_FILTER_MOD
CS_MENU_ENTRY CS_SID_FILTER_CHANNELS, "Ext", 0x01, PRINT_FILTER_EXT, EXEC_TOGPAR, R2PP2R_FILTER_EXT
CS_MENU_ENTRY CS_SID_FILTER_MODE, "3Of", 0x01, PRINT_FILTER_3OF, EXEC_TOGPAR, R2PP2R_FILTER_3OF
CS_MENU_TABLE_FIL_End
[/code]
Another nice table, each line defines a menu item, a "register" (used to identify a parameter in the patch) with text for that menu item, the max value and which functions to handle the printing, selecting and transferring of the parameter to/from the patch.
That is really generalized, and this generalization not only avoids a lot of repeated code for every possible parameter, it makes it really easy to extend, if you wanted to add new parameters.
The point of going into all this detail is to show you exactly what you're suggesting could be replaced (or just edited easier) with a visual tool to make life easier, as well as give you a quick overview of the code should you want to make your own menus. I'm also suggesting that once you learn a bit more ASM and work out how this code all works, then you'll discover that it really isn't that hard to change it to do what you want, be that make a new application or just make changes to the MB-SID application.
gives a little more insight…