0 Members and 1 Guest are viewing this topic.
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.
Quote from: Zemmargorp on August 01, 2014, 08:07:23 pmRegarding 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...
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.
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.
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.
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.
There's no ideal way to provide a reliable write-back.
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).
Hence z80e which aims towards 100% accurate emulation.
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.
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