Author Topic: Release of TilEm2  (Read 24883 times)

0 Members and 1 Guest are viewing this topic.

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Release of TilEm2
« Reply #30 on: March 04, 2013, 01:27:10 am »
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. :)

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

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

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

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.

Quote from: DJ_O
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.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Release of TilEm2
« Reply #31 on: March 04, 2013, 02:06:07 am »
For such macro editing thing, I think it should just be text-based or something, like this:

Keypress   Time held down (in millisecond or whatever is best for the calc, such as clock cycles or whatever it's called. It doesn't matter as long as it remains in sync with emulation)
LEFT    40
<none> 10
LEFT+RIGHT 50
2nd+LEFT 10
LEFT 10
2nd+LEFT 10

And of course you could just display key codes rather than just keys. I'M just typing key names since I forgot the respective key codes. The key codes and time the key is held down would be two text areas (if you click them).

Comments would be nice too (with the ability to jump to them), so for particularly long speedruns you wouldn't have to search for the appropriate key sequence.
« Last Edit: March 04, 2013, 02:18:58 am by DJ_O »

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Release of TilEm2
« Reply #32 on: March 04, 2013, 02:20:36 am »
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.

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Release of TilEm2
« Reply #33 on: March 04, 2013, 03:24:15 am »
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).
Yeah, saving breakpoints would make sense.  Would it be better to associate saved breakpoints with a particular ROM/state file, or make them "global" for all calcs?  I'm thinking probably the former for normal BPs, but maybe "break on invalid instruction" and similar options should be saved as global preferences.

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.

Quote
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.
That's an interesting idea I haven't thought about.  It would certainly be useful in some circumstances.  Legally, I don't see that there would be any problem with sharing .sav files.  The ROM file would be more problematic; maybe a "snapshot file" could be created that stores only the archive contents (requiring the developer in this situation to have a copy of the same OS/ROM version that the user is using.)  Of course, using a .sav file with the wrong OS/ROM version might work in some rare cases but not in general.

Quote
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.
Hmm, you're right.  The fact that Shift+Right isn't the same as just Right is deliberate, so that different key bindings can be assigned to both (and in fact Shift+Up and Shift+Down are mapped to 2nd+Up and 2nd+Down.)  But maybe Shift+Left/Right (and maybe Shift+Backspace and Shift+Del too) should be the same as the unshifted versions.

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Release of TilEm2
« Reply #34 on: March 04, 2013, 03:50:54 am »
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.

Offline utz

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 161
  • Rating: +28/-0
    • View Profile
    • official hp - music, demos, and more
Re: Release of TilEm2
« Reply #35 on: March 04, 2013, 10:31:46 am »
Hi, I just installed the SVN version on my Debian system. First of all I'm absolutely delighted to see that Tilem is still actively developed. Thanks a lot, guys.

I did notice a bug with the new sound feature though. When you change the sample rate and latency settings, the pitch of the output will change, too. I don't think this is how things are supposed to be ;)

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Release of TilEm2
« Reply #36 on: March 04, 2013, 02:11:09 pm »
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. >.<

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Release of TilEm2
« Reply #37 on: March 04, 2013, 09:05:15 pm »
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.
Ah, I see.  That makes things a bit more complicated (what with shift being a modifier and all.)  Maybe I could add an option to customize which modifier bits are used (so, for example, you could set it to ignore Shift completely for purposes of mapping other keys - of course, that would disable left as well as right shift.)  Or you could use xmodmap to globally remap the right shift key, if you don't mind losing its shifty nature.

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.
That's it exactly.  What settings will work will depend greatly on your sound card and drivers.  In my casual experiments, I've found that on my PC, with ALSA software mixing, the latency can be as low as ~20 ms without problems.  With direct hardware access (which you can get by setting AUDIODEV environment variable to "front"; this will prevent other programs from playing sound concurrently) I can set the latency much lower (~3 ms.)  On Windows, however, there seem to be problems with latency smaller than around 100ms.

utz, could you please post a log of the terminal output from tilem and what settings you've tried?  Does it sound okay with the default settings, at least?

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

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Release of TilEm2
« Reply #38 on: March 04, 2013, 11:00:38 pm »
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:
« Last Edit: March 04, 2013, 11:02:32 pm by DJ_O »

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Release of TilEm2
« Reply #39 on: March 04, 2013, 11:24:30 pm »
Interesting.  I can sort of understand why it might be designed that way, especially if the filter is designed to work for a particular ratio of input to output sampling rate.  TilEm's filtering code is fully general (although the math does happen to work out nicely for 15 MHz -> 48 kHz, the code should work correctly for any ratio, within reason.)  So, my inclination would be to say that if you set the emulator to 200% speed, it would simply set the filter to half the output sampling rate (so it plays twice as fast and everything is shifted one octave higher.)

Offline Adriweb

  • Editor
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1708
  • Rating: +229/-17
    • View Profile
    • TI-Planet.org
Re: Release of TilEm2
« Reply #40 on: March 05, 2013, 05:50:15 am »
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. :P
« Last Edit: March 05, 2013, 05:50:50 am by adriweb »
My calculator programs
TI-Planet.org co-admin.
TI-Nspire Lua programming : Tutorials  |  API Documentation

Offline utz

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 161
  • Rating: +28/-0
    • View Profile
    • official hp - music, demos, and more
Re: Release of TilEm2
« Reply #41 on: March 05, 2013, 08:50:23 am »
So I ran a few tests. It seems that the problem occurs only when using Pulse (which is what Tilem will auto-select on my system).
When using Pulse, audio will be wrong regardless of latency/sr settings (even if latency is set to a very high level). As mentioned before, the pitch changes when changing those settings.

audiodev-sdl: Initialized "pulse" driver
audiodev-sdl: buffer size = 2048, latency = 0,064
x2: audio: Starting playback:
x2: audio:  rate        = 48000
x2: audio:  channels    = 2
x2: audio:  format      = 16-bit, signed, little-endian
x2: audio:  buffer size = 4096

Note the mismatch in buffer size, dunno if it's supposed to be like that.

Another interesting thing is that Tilem automatically adjusts the latency setting - the above was run with latency=60, Tilem switches to 64. Well, I don't mind that, as it doesn't seem to cause any problems. This happens with all drivers.

So now the good news: If I switch to Alsa, everything will work as intended, regardless of latency/sr settings.

audiodev-sdl: Initialized "alsa" driver
audiodev-sdl: buffer size = 8192, latency = 0,0929
x2: audio: Starting playback:
x2: audio:  rate        = 44100
x2: audio:  channels    = 2
x2: audio:  format      = 16-bit, signed, little-endian
x2: audio:  buffer size = 8192

Initial latency setting for the above was 96, switched to 93 by Tilem. I can go significantly lower without any problems though.

Btw my setup is: Debian Testing on Solo-Core T60, 2 GB RAM, 1,6 GHz, standard Intel onboard sound.

Hope that helps ;)

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Release of TilEm2
« Reply #42 on: March 07, 2013, 12:40:35 am »
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.)

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: Release of TilEm2
« Reply #43 on: March 07, 2013, 01:31:46 am »
Welcome to the realm of PA-induced issues on programs which work just fine with standard ALSA...
Five years or so after the introduction of that thing (which made contemporary Ubuntu and Fedora highly unpleasant), I still avoid to use it, unless a program requires it, which is fortunately infrequent.

Uninstalling PA completely is not an option on a number of recent, wannabe-user-friendly distros, though. I wish you good luck in making TilEm work with PA...
Maybe PA breaks down with TIEmu as well, I don't know.
« Last Edit: March 07, 2013, 01:50:11 am by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Release of TilEm2
« Reply #44 on: March 07, 2013, 01:37:46 am »
Off-topic question: Will support for TI-84 Plus OS 0.46 ever be added?