I just checked out the new sound features and it's really cool!

Anyway, i've got lots of other feature requests, too (sorry!):

Don't apologize, these are great ideas.

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

-Define a section in memory (width in bytes/height) to preview the contents as if it were the LCD. So if i'm using the gbuf as a buffer, i can type in the address: $9340, the width: 12, and the height: 64 and see a preview of the gbuf.
-A keyboard shortcut to change between full speed and normal calculator speed (more speed options wouldn't be bad, either, in particular slow-motion )
-A "set PC to highlighted line" option (though you can just adjust the PC manually, so it's not super important)
-It'd also be nice to see the HEX code beside the instructions (and optionally be able to change them, like the memory editor beneath it)

All good ideas.  I had originally intended to include "set PC to selection" and forgot about it.

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

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

The ability to edit macros and being able to have delays between each keypress would be nice for tool-assisted speedrunning, along with the addition of slowdowns like WabbitEmu.

That would also be fun; I'm not sure what the best user interface for such a thing would be.  Improving the current macro system is definitely on the to-do list.

Quote

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

Quote

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

Quote

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

Definitively a bug. As for the latency is it so that the sound is played a bit behind in attempt to buffer it? I remember ePSXe emulator had that and setting it up to lower latency allowed sound to be played more in time, although there were risks of crunchy sound if the computer was too slow.

If the emulator ever adds slowdowns/speedups features, though, I think that the sound should be pitched down/up accordingly. WabbitEmu doesn't and it sounds like total garbage when playing a game at slower speed. >.<

Hmm, do you mean that Wabbitemu does apply a time-stretching / pitch-shifting algorithm of some sort?  If so I'm not surprised that it sounds bad.

What Wabbit seems to do is adding silence gaps in the sound when slowing emulation down, and skip audio parts when speeding emulation up. Here are 3 sound examples below, where the first plays at 100% emulation speed, the 2nd at 25% and the 3rd at 400%. The 4th MP3 is the original song:

Quote

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.

Well, if we did it with Lua, you might be able to write a condition like "z80.flags.nz and z80.hl >= 0x8000".  Or "byteat(z80.hl) == 0".  I'd prefer a language with a slightly more assembly-friendly syntax (e.g. bitwise operators and binary constants would be nice) but Lua is nice in that it's small and looks not too difficult to embed.

In fact, with some metatable's tricks, you can have things like "print(myVar1 -xor- myVar2)" etc. (it's basically overloading the "-" operator and looks for its right and left side, then applies the xor functions, etc.

Thanks.  So I've just tested it with pulseaudio in a VM.  I don't see the behavior you're describing where the pitch changes when you change the rate or latency - that's very weird and something is definitely broken.  I do, however, get very "choppy" audio - it sounds as though pieces of the stream are either being dropped or delayed, like PA is trying to synchronize itself with some other clock (and doing a very poor job of it.)  In any case, it's not obvious whether SDL is at fault, or PulseAudio, or TilEm itself.  (It's not because of qemu - when I switch to using ALSA audio inside the VM it works fine.)  I'll have to experiment more to figure this out.

Another thing I've learned is that, apparently, the default setting for PulseAudio is to convert all streams to 44.1 kHz, regardless of the hardware.  This isn't the problem - it sounds just as awful with TilEm set to 44.1k as any other sampling rate I tried.  It is annoying, however, that SDL doesn't tell the application the correct sampling rate to use (the API has a mechanism for doing so, which TilEm uses, but almost none of the SDL audio backends actually implement it.)

Off-topic question: Will support for TI-84 Plus OS 0.46 ever be added?