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.

I've already installed Wabbitemu, but it's not so stable (for me, the latest Axe version doesn't work on it). And TI's flash debugger has a lot of useful features for assembly developers : disassembly, see RAM, etc. No, don't run these checks, it's a bit pointless since there's no ideal way to provide a reliable write-back.

I suspect the problem you're having is that Wabbitemu requires a copy of the boot code/certificate from a real calculator to run 100% accurately. As long as you have a link cable, you should be able to get this easily enough by going to Help > Re-run setup wizard...

And I've never used TI's flash debugger, but I suspect that Wabbitemu's debugging capabilities are as good or better.

I suspect the problem you're having is that Wabbitemu requires a copy of the boot code/certificate from a real calculator to run 100% accurately. As long as you have a link cable, you should be able to get this easily enough by going to Help > Re-run setup wizard...

And I've never used TI's flash debugger, but I suspect that Wabbitemu's debugging capabilities are as good or better.

I've reinstalled Wabbitemu, if one day I want to take an animated screenshot. Oh, I never noticed it had a debugger, which is quite nice, by the way. But I'm used to TI's flash debugger, and it runs faster on my computer (Wabbitemu is a bit laggy).

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.

So do I.

There's no ideal way to provide a reliable write-back.

Tilem seems to be less accurate than Wabbitemu, it's unable to run KnightOS while Wabbit can run it.

Hence z80e which aims towards 100% accurate emulation.

Yeah I know but it's doing some nice progress.

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 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. 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 

You could take a pointer as your argument instead and interpret the memory stored at the pointer instead.

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.