If you have a full size case, take the full size board.

The H81 is more expensive than the H81M. What benefits does having the larger version offer (if any)?

Other ideas : in the Axioms, add a way to make commands which accept between n and m arguments. It can, for example, put the args count in the register B (B because it's the only register used by the DJZN command). This would be[/font] useful for some commands (like "Menu(", of course  ), because if they are used multiple times with different arguments count, the commands' code will only be added once to the program.

Support for varargs functions doesn't exist at all in Axe, whether for Axioms or built-in commands. And I'm pretty sure that the current internal structure wouldn't be very amenable to its addition.

As Eeems said, the only real solution for now is to have the user pass in a pointer to some structure containing all the "arguments", like how you'd ape varargs functions in a language like C. Doing such a thing should be relatively straightforward with static data, as you can just include each argument (or a pointer to each argument) in a static data block. You'll notice that this becomes a lot harder with variable data, as you have to dynamically create the argument structure. This wouldn't be much easier for Axe either, which is why it isn't available.

Also, you don't want the feature you're referencing about a data pointer for this. That simply makes the "command" carry data, and using the "command" just returns a pointer to the data.

Also, maybe add a way to push the arguments after the return address, because it's not very practical the way it is for the person who writes the Axiom 

This isn't really feasible on the calculator, as it only has one stack pointer and there's no way around stacking up all the arguments and only then calling the routine. Architectures get around this by providing multiple stack pointers, one for arguments and one for return vectors, or by providing instructions to fetch indexed stack entries. Z80 provides neither.

I admittedly don't know much about motherboards, but kis there anything wrong with the cheapest motherboard available, the H81M? It's only about $50 and most of the features is lacks shouldn't matter for this build (like 4 RAM slots, crossfire support, extra SATA ports). It even seems to support dual channel memory accesses.

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.

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.

By the way, I tried launching programs from a bunch of shells, and I'm not sure how reliable writeback would be. I found tricky things like DoorsCS and CalcUtil putting the name of their appvars in OP1, and Ion sometimes leaving the name of the program in OP1 but pointing to something that's all zeroes... it all seems a bit too unreliable to me.

I've tried "Disp e8478" with some of these shells, plus Ion you forgot  , and here are the results : it works without any shell, with Noshell, with Mirage OS (v1.2), with zStart (v.1.3.013_83). I wasn't able to download CrunchyOS (I don't know why). Unluckily, CalcUtil and DoorsCS don't work in the emulator I'm using. It doesn't works with Ion (at least for v1.6), but Ion clears OP1's value, so there's no problem.

Using TI's flash debugger, eh? I'd recommend grabbing a much better community-made emulator. My emulator of choice is Wabbitemu. I'll probably run these checks, too.

Quote from: Zemmargorp on August 01, 2014, 08:07:23 pm

Regarding the OS's DIALOG bcalls, I've achieved to find a way to know which item was chosen by the user, in menus like TI-Basic provides. I just need to improve a little the code source... I'll publish it somewhere, but not now.

After two hours of bug-tracking, I've solved a problem I had with the "TI-83+ Flash Debugger". Good to know : sometimes it says some data is located into RAM, whereas it's in Flash ! Nevertheless, I think I've got a stable menu routine ! There's still some little work to do, but I've got a great base (thanks to Brandown and his DIALOG notes and program). Where can I publish it ? Do I make a new topic inside "The Axe Parser project" ? Because if we want to be able to use these bcalls in a reliable way, I'll probably need help from experimented assembly programmers...

That's great! Go ahead and make a new topic in this board with your developments so far. I can somewhat figure out how this all works too, we can get it polished up and ready to go into Axe.

Well yeah, that's why if I'm going to do it, I'm going to do it in Axe 2.0 with probably other language grammar changes that could break existing programs.