This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - FloppusMaximus
16
« on: April 17, 2013, 08:45:06 pm »
DJ: I am surprised and confused by your findings with TI-Connect. Are you certain that the problem you're seeing is due to the resolution change? I haven't tested that specifically, but I would be extremely surprised if in fact changing the resolution (or other display settings such as flipping, scrolling, or cropping the screen) had any effect whatsoever on screenshots. The OS doesn't pay any attention to the LCD settings as far as I'm aware - it should just dump out the contents of GRAM regardless of those settings. At most, I suppose it's conceivable (though unlikely) that changing some of those settings could result in a *corrupted* screen dump - but even if the LCD controller starts feeding the OS complete garbage, the OS should faithfully send 320x240 pixels' worth of complete garbage back to the PC. 160x240 mode is a clever hack, but it's unlikely that it will ever be officially supported by TI. In order to take accurate screenshots in that mode, we'd need to use an assembly program. (If you're trying to get screenshots of a program, you'll have better luck with TilEm.  84+CSE support is still incomplete, but I think somebody mentioned there was an unofficial Windows build?) Anyway, I've done a little work towards supporting 84+CSE screenshots in TILP, but it's more complicated than you might expect - TI broke a lot of the rules. 
17
« on: April 14, 2013, 04:19:40 pm »
Lionel: In fact, the 89/CA commands would, I think, have the same problem that the DUSB remote control command has: namely, that after you send the command, the calc then types out "Asm(prgmROMDUMP)", one token at a time, on the homescreen, which (owing to MathPrint combined with the slow LCD driver) means it takes a second or two for the program to actually be launched. I increased the delay in calc_84p.c to 3 seconds and it seems to work now. The issue with the DBUS dumper was a different one. In that case, I was using the internal link routines (linksw.asm) rather than the system ones - the internal routines don't work when the link assist is enabled. (The OS automatically disables the link assist when it's idle, which is why the program worked when I launched it manually.) Still, nice to know that the software method still works. DrDnar: What you describe (skipping unused areas) is essentially what we do with the TILP ROM dumping protocol. It would also be possible, in theory, to add an option in TILP to dump only the OS and skip the archive/apps completely. I think, though, that the standard behavior of dumping a complete Flash snapshot is a useful one (and it avoids any possible problems with future OSes, from TI or third parties, that occupy a different subset of Flash.) DJ: The issue was really just with the remote program launching; once it's launched, the ROM dumper itself is plenty fast enough. When I tried it before it took about 3 minutes to dump over USB and about 4 minutes with the SilverLink. (My archive is still mostly empty, though; a calc with a lot of programs installed will take significantly longer. I also haven't timed the latest version.)
18
« on: April 12, 2013, 12:00:57 am »
Well, I've finally tracked down all the undocumented system addresses BrandonW used in his DUSB ROM dumper, and it seems to be working now. The DBUS dumper is also working (much faster than tidump, naturally, though not as fast as DUSB.) However, in both cases, remotely launching the program is causing problems. At least part of the problem, I think, is that the homescreen is just *so slow.* In the case of the DUSB dumper, remote launching seems to work in Classic mode but not in Mathprint mode. For the DBUS dumper, it fails in both modes. I'll have to play around more to figure this out.
19
« on: April 06, 2013, 07:30:40 pm »
"Resetting" the port after using it may reduce power consumption slightly, and it might also reduce problems with programs that don't use a long enough delay between the output and input.
You'll also see some programs that "reset" the port before using it rather than afterwards; as far as I know that's a cargo-cult technique that has no benefit whatsoever.
20
« 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.exeSources: tilem-2.1-beta-20130325.tar.bz2 - libti*: SVN r4490, tilp_patchset_20130322.tar.bz2 - SDL: 1.2.15 - libarchive: 3.0.4 - GTK+, etc.: see the tilem project site
21
« 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.
22
« 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?
23
« 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.)
24
« on: March 04, 2013, 11:27:28 pm »
Yep, and we all know TI's calculator division has never done anything dumb. 
25
« 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.)
26
« on: March 04, 2013, 09:35:53 pm »
Well, I would, but that's why I have an OpenPhoenux.
27
« on: March 04, 2013, 09:22:46 pm »
To (belatedly) answer the questions about emulators, ExtendeD hit the nail on the head. Implementing all of the hardware ports on the calc side is rather complicated; I'm planning to do it eventually (in fact, I did some experiments in that direction a couple of years ago), but I haven't found the time to polish it up and make it work properly. It's also true that for calc-to-calc transfers, the sending OS must be the USB host, which would be a bit of a problem for the typical case of running an emulator on your PC and connecting it to a real 84+.
(It should be possible to make bidirectional transfers work on a device that has an OTG port and runs Linux, although I haven't really investigated how hard that would be - and I doubt any current Android devices ship with kernels that support gadgetfs.)
28
« 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? 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.
29
« 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. 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. 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. 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.
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. -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.
|
Show Posts