Yeah, the ticalc version definitely contains two zStart83's.
Also, i'm getting a RAM clear whenever i try to enable >C000 execution on zStart83. It only happens when i exit that menu, but i can't seem to enable >C000 execution. I'm using an 83+ OS 1.19, i tried zStart v.1.3.010 and 1.3.009.
So i just loaded it up and it's pretty cool, the one thing it seems to be missing (apart from the longer words) is a clock! Oh, and thanks for the extra two language packs
I don't know about the 39gII, but that hpcalc.org site lists it under "HP 49/50". The manuals (and the Google Code site) only mention the 50g. I don't know anything about the HP calcs, though, so i can't say.
I can help translate the documentation to English, but there really is a TON of stuff. Seriously, one of the pdf files is over a hundred pages long (though that includes a massive appendix with lots of charts and definitions)!
And due to the screen size you won't be able to see a lot of the words entered (the longer ones), right? Also, would changing wordlist.txt let us potentially make wordlists for other languages (ignoring diacritic marks)? Or is there more to it than that?
Here's a translation of the introduction to the Block Master Builder:
Quote
First thoughts: This tool lets you make games for the BME (v4.0) easily and quickly. You make your games by selecting components from a list and indicating how you want them to function
When you start using the Builder, the best thing you can do is try to get to know and experiment with the different types of components before thinking of tackling a full project. This manual will explain how components work and how to create them.
The next step is the creation of a Zone (ZxPack), which contains a group of components with an objective and either an exit or some other way to win.
In order to create a Zone, we recommend that you start by making a small map containing the components the zone will have and some notes on how you want them to operate, as well as the objectives and how to win the game.
Using the Builder requires a certain precision, seeing as once created components cannot be removed from a Zone, though there are many characteristics which can be modified.
We call the person creating a Zone its "Master", who will have their own style and develop their own building techniques.
The Master can use standard graphics built into the Builder or create their own. On top of that, they can create and incorporate background graphics and animations to give a little style and make the game more appealing.
It's possible to organize a Zone's components into Groups, which lets you modify the state of several components at once (options in key G). This is important because some components such as the MBs {me: Mobile Blocks} and CEs {me again: Complementary Events} consume a lot of the CPUs power and it's better to only have the components presently being used activated and activate others as needed.
* I recommend also studying the Manual of Notes (BMA), which discusses more advanced themes. You can download it from the BM website. I've published the source code and some games which can serve as models as well.
There's loads of documentation and it's all really well organized. If anyone is curious about some part of the documentation just ask.
A couple problems, your variables dX1/2 don't handle negative values. You sort according to Y values, which doesn't mean that the Xs will also be smallest to largest. Also, i don't know how Axe's horizontal line routine would handle it, but if say x1 > x2, it might encounter problems expecting to draw from left to right and not the other way around.
You said you found a better algorithm, but looking at if statements and for loops gives me a headache, so i'm not even going to try understanding it. If you make an assembly version of it i'd be more than happy to look through it, though
Yeah, multiple keypresses work just fine, the only issue seems to be when using shift/control to define special keys. It also seems like keys get queued until the calculator reads them, at least on the homescreen i can type faster than the calculator can handle and it will continue a few seconds afterwards processing the last keypresses. There's also a keymap you can use from the debugger which lets you pick which key groups are being read from/which keys are being pressed.
I think the actual breakpoints would be better stored in each individual ROM/save state, but breakpoint options could definitely be global. I don't see any issue with just storing everything in with the individual savestate, though.
About the keys, i've edited the keybindings.ini file to use Shift (Shift_L) as 2nd, Ctrl (Control_L) as Alpha, and a few other changes to make it closer to the key format of PindurTI as that's what i got used to and any other configuration feels awkward for me (or i'm too lazy to change). It's not a big deal, just that at first i thought it was a problem with my code. I've been trying to get a way for Shift+Right to be treated as 2nd+Right, both being held down, the same way as any two other keys being held down at once.
-Skipping an instruction. Move the PC to the next instruction (useful for jr $ breakpoints) -Related to the previous, a debugger option to treat jr $ as a breakpoint (ie bring up the debugger when a jr $ instruction is executed)
This would be difficult with the current implementation of breakpoints. On the other hand you can easily set (say) "ld b,b" as a breakpoint by setting breakpoint type to "Z80 instruction" and value to 40h. Or you can break on invalid instructions (such as ED00 - but note that that will crash the Nspire.)
That's a great idea and something i'd never thought of before. Thanks! Along those lines it'd be nice to be able to save breakpoints in between sessions or maybe have a tic mark next to them to show that you want TilEm2 to remember that breakpoint next time you start it up. As it is, i often set the same breakpoints each time i'm debugging, especially ranges where i know my program SHOULDN'T be executing code (>$C000 and around <$8500) or for things like setting ld b,b as a breakpoint. It might also be useful to have an option to enable/disable breakpoints altogether (that is, disabling them without removing/clearing them).
-Maybe the debugger could pop up when your code jumps out of the executable code range?
And I actually did some preliminary work toward making this possible but haven't added it to the debugger yet. It'll probably be an option similar to invalid/undocumented instructions - I don't think it should be the default behavior, because I think the debugger can be scary for non-assembly programmers, so it shouldn't ever appear unless it's called for (even if the calculator crashes completely.)
I agree, i think it'd be better to have it turned off by default.
-Conditional breakpoints: stop execution only when a certain flag is set/reset or a register(/register pair) = a certain value.
I'd like to make this possible. I was actually thinking of something even more general: adding a complete scripting language, that could be used both for advanced breakpoint conditions, and for scripted actions (which would be great for automated program test suites, as well as many other applications.) I was thinking about Lua, but other suggestions would be welcome. Of course this would be a significant project in itself.
I can't quite grasp what a scripted language for breakpoints might be like, but it sounds really interesting. I've spent countless hours going through loops trying to figure out where a register is getting messed up or where some wild address is getting pushed onto the stack, so this is something i've often wished for.
I've also wondered about tools for beta testers, things like maybe taking a snapshot of the current system memory to zip up and send to the programmer(s) to try and narrow down what exactly's going on. I can't say if it'd be exactly useful, what you could do to provide information back to the programmer(s), or even if something like that would potentially bring about legal problems. I dunno.
And another kinda out there idea i had while trying to find where a program was crashing was also storing the address where an item on the stack was pushed and maybe having a sort of stack history showing recent values pushed/popped off the stack. Again, sometimes it seems like a feature would be really handy to have and then a week or so later i can't think why i'd ever need something like that.
On a slightly unrelated note, i don't know if you've ever had issues with the keys? Especially when using the Shift key if i want to press another key i have to let go of shift first. If i'm already holding down right and press shift, there's no issue, but if i press shift then try to go right it won't register the second keypress.
I really like the idea of the conditional codes. It's something i really like about ARM assembly, pretty much any instruction can take conditions. So you can do things like addc r1,r2 or even cmpz r1,r2. You can actually also add shifts, so you can do addc r1,r2,r3 LSL 4, which adds r2 + [r3 shifted to the left 4 bits] and stores the result in r1, but only if the carry flag is set (that's one instruction!)
Right now, what does sMask do? I assumed that a sprite wouldn't be processed unless you turned on that sprite's corresponding sMask bit. If i set the sprite delay to 1 and only have one sprite set in the sMask, it'll still process the other 7 sprites before coming back to the one i've enabled?
I think your other ideas are also good, in particular updating the LCD after each sprite is drawn will probably cause quite a bit of a slowdown. Waiting until all sprites have been drawn before updating is probably a good idea. I was also wondering if bit-instructions were going to be added
You'll need to build it from the source at the SVN (svn co https://tilem.svn.sourceforge.net/svnroot/tilem tilem) with SDL installed. Then you can find an option to turn on sound in the Link menu
As for the keypresses, one thing you can do albeit a bit more complicated is after pressing a key have a timer that counts up until you release it. Once you reach a certain value you can start another timer which will let you scroll more quickly. So when you press the key there will be a short delay before the next repetition kicks in after which it'll scroll more quickly (like the TI OS menus/cursor). Or if you repeatedly press a key it'll scroll quickly, too. And another option for the note names might be to just place an octave number first then the note name, ie 1C# would be the lowest note and 4G# would be the highest. Maybe an apostrophe or something next to the note could indicate a sharp sign.
Anyway, it's a really cool program and especially if we can get it ported to some more popular calculators i think a lot of people could really have fun with it.
I've been having a bit of trouble getting other keys to work correctly, maybe i'm not quite doing something right or maybe i'm missing something. Anyway, i've got this code (which when thinking of how it might translate into assembly makes me shiver ):
;##_key 0_## key0= 29h kDown= $FE kLeft= $FD kRight= $FB kUp= $F7The sprite doesn't really seem to move, however. Sometimes it will jump to the middle of the top row, but never moves up or down. I've also gotten a couple crashes so far, some from mistyping the hex Can you think of an easier way to transfer programs apart from typing them by hand? I tried prefixing the quote with the " token and ending it with ->Str0, but when running the basic interpreter complains about some of the compiled tokens and it won't store the entire string into Str0. Another idea might be a little [On]+[Clear] interrupt to forceably quit a program.
The ion include file i downloaded from ticalc has this:
So i just tried this out with the new TilEm2 and it's super cool. The only thing is that the keys don't seem that responsive. I had fun just putting in random numbers and listening to what came out
Show Posts
Can you think of an easier way to transfer programs apart from typing them by hand? I tried prefixing the quote with the " token and ending it with ->Str0, but when running the basic interpreter complains about some of the compiled tokens and it won't store the entire string into Str0. Another idea might be a little [On]+[Clear] interrupt to forceably quit a program.