Omnimaga

Omnimaga => News => Topic started by: contra-sh on June 08, 2012, 06:06:42 am

Title: Release of TilEm2
Post by: contra-sh on June 08, 2012, 06:06:42 am
TilEm is dead, long live TilEm2

Benjamin Moody (floppus maximus) and myself Thibault Duponchelle(contra-sh) are proud to announce the first release of TilEm2.

You probably already know TilEm "old" because it was a good emulator serving the community since 2000 (written by Julien Solignac then improved and maintained by Moody Benjamin)
For those who don't know, TilEm is an emulator that reproduce behavior of z80 based Texas Instrument Calculator (TI73 through TI86 including the TI81 :p). As the others emulators, TilEm2 needs an official rom of course.

TilEm old was available for GNU/Linux natively then ported to Windows and Mac.
TilEm2 is already available for GNU/Linux and Windows (TilEm2 is likely to work on Mac OS X, but we have not tested it)

3 years ago, I joined the team and we started to work on a new version of TilEm.
Even if it seems to be a sequel, all the code was written from scratch, including a new emulation core written by Benjamin.

This new version is released for beta testing.

It features highly detailed hardware emulation.
TilEm 2's hardware emulation is greatly improved - it's now at least on par with, and in some cases better than, any other emulator released to date. 
All of the Z80 models are supported (including both hardware revisions of the TI-81 and both revisions of the TI-82); the only part of the hardware that is not currently emulated is the TI-84 Plus USB controller.
 
Sending/receiving programs, variables, and applications :

Grayscale emulation :

Saving screenshots :

A full featured debugger for assembly programming :

Macro :

New pack of skin and new skin format (TiEmu skin file) :

This version has a new and improved user interface, as well as many
improvements to the hardware emulation.
See the project website at http://lpg.ticalc.org/prj_tilem/ (http://lpg.ticalc.org/prj_tilem/) for more
information.

This release is only a step, development goes on. We will add some new features to TilEm2 soon. In addition to the features you will request and bug we will have to fix.
You will find a long user manual here : http://contra-sh.users.sourceforge.net/user_manual.html (http://contra-sh.users.sourceforge.net/user_manual.html)
This program was made for YOU users.
Please report bugs and feature request (on the Sourceforge forum : http://sourceforge.net/projects/tilem/forums/forum/84646 (http://sourceforge.net/projects/tilem/forums/forum/84646))
The current maintainers of TilEm are Benjamin Moody and Thibault Duponchelle (but many other people have played a part in making this program possible especially Hugues Luc Bruant "fullmetalcoder" who started a qt gui and helped us a little for other stuff and Scott Zeid which provides the pictures from which are based the icons).

Have fun with TilEm2 !!!

Liens :

Official website (http://lpg.ticalc.org/prj_tilem/)
Download TilEm2 (http://lpg.ticalc.org/prj_tilem/download.html)
PDF documentation (http://lpg.ticalc.org/prj_tilem/doc/user_manual.pdf)
Online Doc (http://contra-sh.users.sourceforge.net/user_manual.html)
Contact (http://sourceforge.net/projects/tilem/forums/forum/84646)
Title: Re: Release of TilEm2
Post by: Juju on June 08, 2012, 08:54:53 am
Nice, I'll try this tonight.
Title: Re: Release of TilEm2
Post by: TIfanx1999 on June 08, 2012, 10:13:21 am
Wow, very nice. I haven't seen any news about tilem in years. It's always nice for the community to have more options for these sort of things. ^^
Title: Re: Release of TilEm2
Post by: shmibs on June 08, 2012, 10:52:32 am
it looks pretty great =)
the gui is still a bit blurry, though, probably because of the arbitrary resizing stuffs.
here's a screenshot:
oh, and it doesn't seem to come with any skins, so you can use this quick 84+ one to test it out and then make your own with skinedit (http://www.ticalc.org/archives/files/fileinfo/232/23201.html) and this (http://tiplanet.org/forum/archives_voir.php?id=1066) collection of calc images from tiplanet. just make sure that images you use have no alpha channel or the program will crash.
Title: Re: Release of TilEm2
Post by: alberthrocks on June 08, 2012, 11:03:48 am
Nice! :D I've heard about this in the works, so it's great to see it working! :D
Title: Re: Release of TilEm2
Post by: contra-sh on June 08, 2012, 11:16:15 am
Thank you :)
And it really works (and really rocks) :P
Title: Re: Release of TilEm2
Post by: ACagliano on June 08, 2012, 11:17:11 am
I'd like to make a request. When you guys officially get the Mac working, please distribute it as either an installable package or as a .APP file, not something you have to do...

Code: [Select]
./configure
make
sudo make install

...on. :) I hate those.
Title: Re: Release of TilEm2
Post by: contra-sh on June 08, 2012, 11:43:12 am
Ok,

But we firstly need someone to help us to package for Mac OS X because we are not Mac users :(


Title: Re: Release of TilEm2
Post by: shmibs on June 08, 2012, 11:47:53 am
this looks like it might be what you'll need:
http://sourceforge.net/apps/trac/gtk-osx/
Title: Re: Release of TilEm2
Post by: Deep Toaster on June 08, 2012, 11:57:55 am
Wow, that looks really nice.
the gui is still a bit blurry, though, probably because of the arbitrary resizing stuffs.
Glad to hear it has arbitrary resizing, anyway :D
Title: Re: Release of TilEm2
Post by: Juju on June 08, 2012, 01:57:18 pm
I own a Mac, I'll probably try to do something. You could package it with MacPorts or something. (That's what I'm doing atm, compiling it with libs found in MacPorts.)
Title: Re: Release of TilEm2
Post by: aeTIos on June 08, 2012, 01:59:30 pm
Well, I've installed this, but it doesnt seem to either like my ROM or work correct... (I dumped my ROM via TiLP)
It's just showing a blank screen.
Title: Re: Release of TilEm2
Post by: Adriweb on June 08, 2012, 04:28:48 pm
I own a Mac, I'll probably try to do something. You could package it with MacPorts or something. (That's what I'm doing atm, compiling it with libs found in MacPorts.)
I got some pkg-config errors while trying to ./configure
Title: Re: Release of TilEm2
Post by: Juju on June 08, 2012, 04:32:17 pm
I own a Mac, I'll probably try to do something. You could package it with MacPorts or something. (That's what I'm doing atm, compiling it with libs found in MacPorts.)
I got some pkg-config errors while trying to ./configure
I didn't, IIRC. Make sure you have the pkg-config package installed. Installing GIMP should be enough, I think.
Title: Re: Release of TilEm2
Post by: FloppusMaximus on June 08, 2012, 10:37:58 pm
the gui is still a bit blurry, though, probably because of the arbitrary resizing stuffs.
Scaling to arbitrary sizes, accurate scaling, sharp pixel graphics: pick any two.
(If you prefer sharp graphics over accuracy, then you can turn off smooth scaling in preferences.  But I think that looks awful.)

Well, I've installed this, but it doesnt seem to either like my ROM or work correct... (I dumped my ROM via TiLP)
It's just showing a blank screen.
I'm guessing this means you're using one of the calc models for which we don't yet have a skin.  (Oops, maybe we should have made that clearer.  Sorry about that.  And we should probably use other model skins as fallbacks.)  If you have a skin in TiEmu format (such as the one shmibs posted), you can select it in the preferences, or pick one of the ones installed with TilEm (they're in the share/tilem2/skins directory.)  Also, you can use the keyboard; see the KEYS file (KEYS.txt in the Windows distribution) for details.  F12 is the On key. :)

If anyone has a high-quality image of their calculator that we could use for a skin, and would be willing to release it under a free license so we can include it with TilEm, that would be fantastic.  Calculators we're currently missing skins for are TI-73, TI-83+ SE, TI-84+ SE, Nspire, and TI-85, and I wouldn't say no to a nice TI-82 STATS.fr skin to round out the collection. :)
Title: Re: Release of TilEm2
Post by: Darl181 on June 08, 2012, 11:07:19 pm
Might it be worth it to make skins for the 84 Pockets (.fr and SE) as well?  Tho it would be kind of redundant :P
Title: Re: Release of TilEm2
Post by: FloppusMaximus on June 08, 2012, 11:20:03 pm
Sure, why not.  The French keypad would be a nice addition for some folks, I'm sure.
Title: Re: Release of TilEm2
Post by: apcalc on June 09, 2012, 08:37:05 am
Great news!  I will need to give this great program a try! :)
Title: Re: Release of TilEm2
Post by: aeTIos on June 09, 2012, 09:52:28 am

Well, I've installed this, but it doesnt seem to either like my ROM or work correct... (I dumped my ROM via TiLP)
It's just showing a blank screen.
I'm guessing this means you're using one of the calc models for which we don't yet have a skin.  (Oops, maybe we should have made that clearer.  Sorry about that.  And we should probably use other model skins as fallbacks.)  If you have a skin in TiEmu format (such as the one shmibs posted), you can select it in the preferences, or pick one of the ones installed with TilEm (they're in the share/tilem2/skins directory.)  Also, you can use the keyboard; see the KEYS file (KEYS.txt in the Windows distribution) for details.  F12 is the On key. :)

Hm but it's a 84 plus rom?
 EDIT:
Silly me, I didnt know that the calc screen was white when turned off. Works now!
Title: Re: Release of TilEm2
Post by: Juju on June 09, 2012, 01:20:50 pm
Hm. I'll give building and packaging stuff for Mac a try.
Title: Re: Release of TilEm2
Post by: parserp on June 09, 2012, 01:42:36 pm
Whoa... A REAL emulator? O.O

jk looks nice :D
Title: Re: Release of TilEm2
Post by: FloppusMaximus on June 09, 2012, 11:58:42 pm
Hm but it's a 84 plus rom?
 EDIT:
Silly me, I didnt know that the calc screen was white when turned off. Works now!

I replied to your post on Cemetech, but I want to emphasize this: apparently, the TiLP USB ROM dumper has a bug, in that it reports a ROM size of 2 MB for both the 84+ BE and SE.

So if you have an 84+ BE, and dump your ROM using TiLP 1.16 and a direct USB cable, it will produce a ROM file that is twice the size it's supposed to be.  Although this may appear to work if you select "TI-84 Plus Silver Edition" as the calculator model, it will have some serious problems sooner or later (anything involving Flash won't work.)
Title: Re: Release of TilEm2
Post by: aeTIos on June 10, 2012, 08:40:18 am
Yup, that is right. None of my APPs got transferred to the ROM. Any other ways to dump a ROM?
Title: Re: Release of TilEm2
Post by: shmibs on June 10, 2012, 12:24:03 pm
Hm but it's a 84 plus rom?
 EDIT:
Silly me, I didnt know that the calc screen was white when turned off. Works now!

I replied to your post on Cemetech, but I want to emphasize this: apparently, the TiLP USB ROM dumper has a bug, in that it reports a ROM size of 2 MB for both the 84+ BE and SE.

So if you have an 84+ BE, and dump your ROM using TiLP 1.16 and a direct USB cable, it will produce a ROM file that is twice the size it's supposed to be.  Although this may appear to work if you select "TI-84 Plus Silver Edition" as the calculator model, it will have some serious problems sooner or later (anything involving Flash won't work.)

what do you mean? when i open TiLP with either an 84+ or 84+SE connected through direct USB, the option for ROM dumping is always greyed out, and the TiLP user manual says:
- TI84+ / USB : no dumper yet
Title: Re: Release of TilEm2
Post by: Lionel Debroux on June 10, 2012, 12:28:31 pm
Quote
when i open TiLP with either an 84+ or 84+SE connected through direct USB, the option for ROM dumping is always greyed out,
It shouldn't be. Which TILP version are you using ?

Quote
and the TiLP user manual says: - TI84+ / USB : no dumper yet
I may have forgotten to update the manual ^^
Title: Re: Release of TilEm2
Post by: shmibs on June 10, 2012, 02:51:36 pm
i'm using TiLP2 - Version 1.17, installed through the linux autoinstall script. the option for "Dump Rom" in the dropdown menus is greyed out, but after playing around for a bit, i just successfully dumped it by double clicking on Operating System in the left pane.
Title: Re: Release of TilEm2
Post by: Lionel Debroux on June 10, 2012, 03:20:28 pm
Problem fixed and documentation slightly updated, thanks for the report :)
Title: Re: Release of TilEm2
Post by: Darl181 on June 10, 2012, 04:10:58 pm
Any other ways to dump a ROM?
Try rom8x, it worked for me.
http://www.ticalc.org/archives/files/fileinfo/373/37341.html
It doesn't dump it per se, it makes appvars which you send to the computer and put together using cmd.  No special linking stuff needed :)
Title: Re: Release of TilEm2
Post by: chickendude on March 03, 2013, 02:09:33 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!):
-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)
-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)
-Maybe the debugger could pop up when your code jumps out of the executable code range?
-Conditional breakpoints: stop execution only when a certain flag is set/reset or a register(/register pair) = a certain value.

There are already a ton of features that i'd never thought of before but which i use everyday now, like the execute until ret feature and the run 'til next line feature. Also, the read/write breakpoints are really handy. Thanks a bunch to you and contra!

(EDIT: And these are just ideas, please don't think they're demands or anything like that!)
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 03, 2013, 03:49:02 am
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. :P

(http://www.omnimaga.org/index.php?action=dlattach;topic=1935.0;attach=1055;image)

(http://www.omnimaga.org/index.php?action=dlattach;topic=1935.0;attach=2034;image)
Title: Re: Release of TilEm2
Post by: FloppusMaximus 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.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga 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.
Title: Re: Release of TilEm2
Post by: chickendude 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.
Title: Re: Release of TilEm2
Post by: FloppusMaximus 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.
Title: Re: Release of TilEm2
Post by: chickendude 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.
Title: Re: Release of TilEm2
Post by: utz 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 ;)
Title: Re: Release of TilEm2
Post by: DJ Omnimaga 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. >.<
Title: Re: Release of TilEm2
Post by: FloppusMaximus 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.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga 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:
Title: Re: Release of TilEm2
Post by: FloppusMaximus 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.)
Title: Re: Release of TilEm2
Post by: Adriweb 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
Title: Re: Release of TilEm2
Post by: utz 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 ;)
Title: Re: Release of TilEm2
Post by: FloppusMaximus 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.)
Title: Re: Release of TilEm2
Post by: Lionel Debroux 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.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 07, 2013, 01:37:46 am
Off-topic question: Will support for TI-84 Plus OS 0.46 ever be added?

(http://www.omnimaga.org/index.php?action=dlattach;topic=14819.0;attach=14792;image)
Title: Re: Release of TilEm2
Post by: FloppusMaximus on March 07, 2013, 02:05: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.
Yeah... I tried it briefly some years ago, found it did nothing but break other programs, and removed it.  One way or another, though, TilEm either has to support it or work around it somehow.

Off-topic question: Will support for TI-84 Plus OS 0.46 ever be added?
As far as I know it does work (I've never heard anything to the contrary); is there a reason to think it wouldn't?
Title: Re: Release of TilEm2
Post by: utz on March 07, 2013, 06:36:40 am
Welcome to the realm of PA-induced issues on programs which work just fine with standard ALSA...

Hahaha good one! Now let's introduce some output filtering via Jack to make things perfect  :devil:

Jokes aside, if this can't be fixed easily then just drop Pulse support, or at least don't select it as default option. Users with a full Pulse setup can simple reroute ALSA anyway.
Title: Re: Release of TilEm2
Post by: Xeda112358 on March 07, 2013, 07:22:10 am
Wow, this seems awesome o.o I have a question because I think i misunderstood something. Is there an issue with pressing multiple keypresses at once? I have made programs that could take >4 simultaneous keypresses, so that could be a problem. This also made me wonder if your macros were able to support multiple key presses at once, because that could be useful.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 07, 2013, 02:25:07 pm
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.
Yeah... I tried it briefly some years ago, found it did nothing but break other programs, and removed it.  One way or another, though, TilEm either has to support it or work around it somehow.

Off-topic question: Will support for TI-84 Plus OS 0.46 ever be added?
As far as I know it does work (I've never heard anything to the contrary); is there a reason to think it wouldn't?
I tried it and it didn't work at all: All I get is a blank screen and no skin. The ON key doesn't do anything, nor trying to change the contrast. In WabbitEmu it didn't go further than the RAM Cleared screen.

EDIT: Actually disregard my post. I was pressing Esc instead of F12 >.<. I forced a TI-84+ skin with the ROM through the option and clicking the ON key from there worked too and it appears to work so far. The only issue remaining being how the ROM has no skin assigned to it (In WabbitEmu it defaulted to a 83+SE skin)
Title: Re: Release of TilEm2
Post by: FloppusMaximus on March 07, 2013, 09:20:04 pm
You can certainly have multiple keys pressed at a time (with the keyboard, simply pressing two keys at once; with the mouse, by middle clicking to hold a key down.)  Multiple key *sequences*, though (such as pressing "A" to yield "Alpha, Math") are queued up and run sequentially, rather than simultaneously; this is by design.  As for macros, macros currently only record which keys are pressed, not when or how long they are held down; this is certainly an area that could use improvement.

Note also that many PC keyboards, particularly cheaper ones, aren't designed to allow arbitrary combinations of keys simultaneously; certain combinations simply won't be reported to the PC, either because the keyboard physically can't tell which keys are being pressed, or (in the case of USB keyboards) because of protocol limitations.

DJ_O: Thanks for reminding me about skins; I should set it up to use fallbacks for the missing skins.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 07, 2013, 11:25:18 pm
AH I see about the macros. Time would definitively be a good addition since right now when you play a macro it just processes every key with almost no delay between them :P (which can be unreliable since it doesn't leave enough time for loading sequences or LCD display/refresh.

I think macros like that could be useful if someone decides to test a calc game and have to go through a very hard part that he absolutely have to go through to ensure that the rest of the game works correctly, such as boss fights with multiple parts or very hard puzzles.
Title: Re: Release of TilEm2
Post by: chickendude on March 08, 2013, 01:42:36 am
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.
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 08, 2013, 02:04:57 am
Another thing I noticed is that for keys with quick key repeat like arrows and DEL, you can move faster when pressing keys repeatedly (as seen in the 1st screenshot below) than holding them down (as seen in the 2nd). Of course an human would most likely not gonna be able to do this in real time, though, even if he's really good at key mashing. It was done around 5% speed so it could have been even faster, but wasn't because I had to constantly alternate between the down and left key to ensure that each of my keypress won't get registered as holding the down key down.
/me wishes there was some sort of Dactylo game for calcs that measured your WPM :P
Title: Re: Release of TilEm2
Post by: FloppusMaximus on March 26, 2013, 02:24:35 am
Announcing (finally) the first beta version of TilEm 2.1!

The major changes since version 2.0 are:
 - Audio support.  Known to be broken with PulseAudio - see utz's comments above.
 - External link cable support.  Please note that under Windows you will need to install TILP in order to use external link cables.  On other platforms, using the latest libti* from SVN is recommended for BlackLink/ParallelLink support.
 - French translation added (thanks to contra-sh for all his work on this.)
There are lots of minor improvements and bug fixes as well.

Please test this version and let me know if you find any problems.  I would particularly like to know how well audio and external link cables work on Windows.

Windows installer: tilem-2.1-beta-20130325.exe (http://tilem.sourceforge.net/beta/tilem-2.1-beta-20130325.exe)
Sources: tilem-2.1-beta-20130325.tar.bz2 (http://tilem.sourceforge.net/beta/tilem-2.1-beta-20130325.tar.bz2)
 - libti*: SVN r4490, tilp_patchset_20130322.tar.bz2 (http://tiplanet.org/beta/tilp_patchset_20130322.tar.bz2)
 - SDL: 1.2.15
 - libarchive: 3.0.4
 - GTK+, etc.: see the tilem project site
Title: Re: Release of TilEm2
Post by: DJ Omnimaga on March 26, 2013, 03:02:09 am
Glad to hear! I will try this when I have some time. (most likely with Utz's sound programs) :)
Title: Re: Release of TilEm2
Post by: chickendude on March 29, 2013, 07:48:02 am
I just thought of another breakpoint feature request: defining an address or address range where it won't trigger a breakpoint. For example, if i'm watching a player's coordinates for changes, i know that the player movement routines should be writing to those values, so i can turn off breakpoints for that address range to only break when i shouldn't be writing there. I dunno how often you'd really want to use it, but right now i'm wishing i could do that ;)

EDIT: The preferences menu covers up the LCD, it would be nice if we could move it. It would also be nice to still be able to control the calculator with the preferences menu open (or have a short cut to toggle between full speed and 100% speed).
Title: Re: Release of TilEm2
Post by: utz on June 05, 2013, 11:18:53 am
I noticed Tilem2 currently has no TI-73 skin. So I made one. Download here (http://irrlichtproject.de/downloads/ti73.skn).
Title: Re: Release of TilEm2
Post by: FloppusMaximus on June 06, 2013, 08:49:07 pm
Great!  Is the image your own work, or do you know if it's freely licensed?  It'd be really nice if we could include it in the TilEm package.

I've finally (I believe) found and fixed the pulseaudio problem - if you have a chance, could you please test it?  For the record, the problem was a silly mistake on my part; while pulseaudio undoubtedly has some problems, this particular issue wasn't its fault or SDL's. :-\
Title: Re: Release of TilEm2
Post by: utz on June 07, 2013, 07:09:11 am
The skin is based on an image that can be found on various reseller websites. I'd argue that, being just an image of a calculator, the threshold of originality isn't reached and therefore it's PD, and the metadata contains nothing to suggest otherwise. But I can't say for sure. If someone provided me with an appropriatly licensed image, I'd be willing create another skin.

Pulse sound still doesn't work correctly on my machine. But I have some issues with my audio drivers at the moment, so there's a slight chance that those are at fault. Need to wait for some packages to be moved to Debian Testing.

Edit: It seems that at the moment, sound output isn't very accurate in general. Just tried on Windows, it doesn't sound good. Check the examples included here (http://irrlichtproject.de/downloads/ti1bit.zip) and compare to sound output from VTI, you'll hear what I mean. VTI isn't perfect (too much hi freq filtering), but otherwise it's more or less how it sounds on real hardware.
Title: Re: Release of TilEm2
Post by: FloppusMaximus on June 08, 2013, 01:56:25 am
The skin is based on an image that can be found on various reseller websites. I'd argue that, being just an image of a calculator, the threshold of originality isn't reached and therefore it's PD, and the metadata contains nothing to suggest otherwise. But I can't say for sure.
That will not be good enough, I'm afraid.

Quote
Edit: It seems that at the moment, sound output isn't very accurate in general. Just tried on Windows, it doesn't sound good. Check the examples included here (http://irrlichtproject.de/downloads/ti1bit.zip) and compare to sound output from VTI, you'll hear what I mean. VTI isn't perfect (too much hi freq filtering), but otherwise it's more or less how it sounds on real hardware.
That's unfortunate.  Thanks for the information; I'll have to experiment a bit to figure out what's going on there.