The OS does not expose a very simple way to generate menus, which is why the feature does not exist. But if any assembly wizards want to provide the majority of a solution, I'll happily include it! That is, if I can fit it. :P
;Does anyone knows why it's actually required to change these flags for a menu ?The OS's all-input routines use the raw key scanning commands along with raw key hooks, so those latters must be saved before and restored after calling such BCALLs.
;<-- What does this line exactly does ?Port 6 controls the flash page currently mapped to $4000-$7FFF. I guess the BCALL maps another page to this zone, so the current page (retrieved with in a, (6)) must be saved in A for future restore. That's only supposition though.
;Is it always the case ? Does anyone know why ?As I said above, the BCALL may map a specific flash page to $4000-$7FFF, so there's no reason why it wouldn't write the answer to an equally specific page. Also, page 1 is not flash but RAM, actually the only memory allowing for write.
;What does this line does ?According to WikiTI :
Official Name: appCurWord
Set to have the text cursor cover the entire token.
;There must be an easier way to do this.textShadow is $8508 and only 128 bytes large, so :
ld hl, $8508
ld de, $8509
ld (hl), 0
ld bc, 127
ldirActually, this only erases the screen's backup. The job of textShadow is to hold a copy of the large-font chars that were on your screen before you changed context (by entering a menu for example).The OS's all-input routines use the raw key scanning commands along with raw key hooks, so those latters must be saved before and restored after calling such BCALLs.Ok. I don't know if it's that useful, because this hook isn't probably changed all the time, but I'll let it.
Port 6 controls the flash page currently mapped to $4000-$7FFF. I guess the BCALL maps another page to this zone, so the current page (retrieved with in a, (6)) must be saved in A for future restore. That's only supposition though.Thanks, so that's the reason why the selection's index is stored there.
As I said above, the BCALL may map a specific flash page to $4000-$7FFF, so there's no reason why it wouldn't write the answer to an equally specific page. Also, page 1 is not flash but RAM, actually the only memory allowing for write.I thought RAM was page 0 ?... A lot of bcalls, like "FindSym", returns B=0 if the value is in RAM, and else the page's number the variable is in. In fact, you mean they return B=0 if it's in the current flash page mapped, and B>0 otherwise ? But then I should be able to get this value without using bcall(_LoadCIndPaged) ? I didn't achieved to do it...
The job of textShadow is to hold a copy of the large-font chars that were on your screen before you changed context (by entering a menu for example).So we should use it to backup the screen before the menu is set, and restore it later.
There are two RAM pages ; page 0 is mapped in $8000-$BFFF and page 1 is mapped in $C000-$FFFF. Else you would have 16kb of RAM, not 32kb ! (although only 24 are usable). It's just that ChkFindSym returns DE > $BFFF and B = 0 if the variable is in page 1. That's why it says B=0 is RAM.Thanks for this explanation... So the instruction "in a, (6)" is here to make sure the page needed is mapped before making the bcall. But then, how could we restore the previous page mapped ? because the command should restore it before returning !
ld b, 1
ld hl, $8006
bcall(_LoadCIndPaged)
ld h, 0
ld l, c
I've been playing with this for a while now. It seems that, at least for simple menus, this should be totally capable. But one problem I've run into so far is that, if I move the cursor into and then out of the number entry field, the dialog glitches out. Does this happen for you too, and/or do you have any idea why this would be happening?Yes, it works very good for simple menus. We just need to create a function which will create automatically the menu structure into ramCode. I've not currently tested the number input (I'll do it later), and I don't know why this happens... I'm trying to make a MENU Axiom, but I have got a problem (see the spoiler). Also, it would be great to increase the maximum arguments for a command to 8 instead of 6 ! By the way, in the code I posted above, I've noted all the things the routine changes and doesn't restore. Do you think some of them can be annoying, and we should find a way (even if it takes some more bytes) to restore them ?
I'm not sure what shell you're trying to compile this for, but right now your shell compatibility byte is 0xCF = 0b11001111. That means that it's incompatible with applications and Axe fusion. If that isn't the issue, I can't say what the issue is by looking at that.I'm trying to compile it to "No shell", as I always do - I never compile either to apps or to Axe Fusion (as it's buggy). I also tried other values : 0xFF for compatibility, and 0x01 for arguments, but it doesn't work, and I can't figure out why. I'll disassemble some Axioms to see how it works... But right now, I don't understand why I get the error "INVALID TOKEN".
As for increasing the number of arguments allowed, I'll look into it. Although I had a quick glance at the Axiom parsing code and was absolutely clueless about how it even checks the number of arguments, so it might not be easy for me to figure out.Thanks. And it seems that Axe Parser doesn't recognize Axioms which starts with the header of compiled programs, even if then follows the Axiom header. It would be great to allow it.
What assembler are you using ? The .org preprocessor instruction have different behaviors depending on assemblers.I'm using TASM. I know it has issues with the org directive, but I don't think it's the cause of my problem... I removed it, and I still have the same "INVALID TOKEN" error.
.org physically moves PC, as in, if you do .org $+8, the final compiled program will effectively have 8 zero bytes in the middle. I don't think TASM can do anything else related to PC, so I strongly recommend you using another assembler. I use SPASM, whose .org directive works the way you intend it to.Downloading... Editing the "compile.bat" file... Compiling... Adding the file "AXIOM.8XP" generated to TI-Flash debugger... Wait ! :o It works ! There's no more "INVALID TOKEN" error ! I don't know what it changed, but thanks ! :thumbsup: Now I can really start writing the Axiom...
Download SPASM : http://wabbit.codeplex.com/releases/view/45088 (http://wabbit.codeplex.com/releases/view/45088)
Wait ! :o It works ! I don't know what it changed, but thanks ! :thumbsup:I take back what I said ! (I'm kidding, of course I thank you : without you I would still have this error.)
Wait, that means you can only have up to 5 choices right ?No ! You can have up to 7 choices ! If you had downloaded the zip (nobody did, but I got two points of karma : that's funny !), you'd have seen I provided an alternative which consists of generating data corresponding to the menu (I've made a generator in the zip), and sending an pointer to the data using this syntax : "Menu(GDB0)rr".
Also, maybe you can display the title in inversed font, like Basic menus.
Apart from this, well done ! I'm sure many persons were waiting for this to pop out :)
Les Français vaincront ! :D
YES finally! A quick alternative to creating your own menu system every time you write an axe program! This slipped under my radar, but I am glad I see it now!In fact, I published it today, so you're one of the first people to see it !
This is interesting. I will most likely not use it since I don't code in Axe anymore but I know some people might not necessarily need complex menus in their games and might just want to use the default TI-OS ones. In BASIC too it was pretty convenient and not too intrusive, game-design-wise, so it's good that they can now be used in Axe too. :)Thank you. And, yeah, I'm one of these people who might not necessarily need complex menus...
If I was you, I would make it as simple as BASIC did, but perhaps with extra options and the ability to have more than 7 items at once. In BASIC, for example, it's impossible to make the title so that it uses black text on white background like the rest, and you are limited to a maximum of 7 menu items. Of course it would depend how much space there is for this, though.It'd be better to have the title in inverted color, but currently, the only way I found to display the title is in black on white. And I'd love to find a way to have more than 7 items, but adding items beyond 7 makes it crashing...
Couldn't you use set 3,(iy+5) before writing the title, then res 3,(iy+5) after writing it to have it written in inverted color ?No, I thought of it, but the menu is written in one fell swoop by the OS's routine, which must configure all the flags before.
.BUGGY
#Axiom(MENUS)
Menu("TITLE SCREEN","CHOICE1","CHOICE2","CHOICE3")
It seems there is a conflict between your axiom and zStart (which would be quite annoying, because it is a very common shell) :
I had zStart installed (with every options activated), and I ran the following program (once compiled with Axe) :Code: [Select].BUGGY
#Axiom(MENUS)
Menu("TITLE SCREEN","CHOICE1","CHOICE2","CHOICE3")
The program worked fine, but after the execution, almost every zStart's hooks were off : only the custom font was still on.
A bit of testing seems to suggest that it's some compatibility issue with Omnicalc and/or zStart.