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
1
« on: October 02, 2013, 08:21:44 pm »
Good luck stopping unsigned lol. I made that program possibly the most annoying program for TI to debug. Not only is the entire program encrypted, but it has like 8 different hardware checks that it performs to make sure it's not running on an emulator. My favorite part is that a few of the checks crash it, a few of the checks freeze, and finally, the last few checks make it look like it worked when in reality nothing happened.
As an emulator author I know I ought to be offended at the idea of emulators being imperfect; as a realist I know that of course they inevitably are; and as a fan of third-party OSes I'm just amused. Well done, though I may need to have a go at cracking your program myself.  It seems that the new TI-83 Plus.fr USB in France (which use the TI-84+SE hardware) have their Boot Code write protected: EpicFail and Flashy don't work anymore.
This, to be honest, is probably a good thing. Is the boot code the same as the older 1.03?
2
« on: September 13, 2013, 12:38:34 am »
Hardware-wise? It is, as far as I know, exactly the same hardware as the TI-83 Parcus, except that it has a 128k ROM chip instead of 256k. So, indeed, the link port works the same way as on the 83, as does the battery testing circuit.
Software-wise, of course, it's still an 82 inside, and apart from the changes needed to support the new hardware, there's not much that was changed in the OS.
3
« 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. 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 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.
4
« 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. 
5
« on: May 08, 2013, 10:48:26 pm »
When I try to send an OS to my 83PSE or 84PSE, it gets through the point where the calculator says '0% Completed', and when it gets past sending the first page of the OS, the calculator says that there was an error, and the computer waits until the timeout time is past until it shows a timeout error. The direct USB OS sending works fine, and I can receive OSs from my friend's calculators with either link cable. Thanks. I don't know why it would be doing that, but I'll check it out. To be clear, are you trying to send an official OS file from TI, or a third party OS? Also, if you can, it'd be really helpful if you could post the log file (usually stored in "C:\Documents and Settings\username\.tilp.log") after trying to send an OS.
6
« on: May 07, 2013, 10:32:22 pm »
The ROM dumpers do work. Must be something wrong with the Windows build. Does ROM dumping work for other models? the lack of a working silverlink OS sender
Elaborate, please. when you right click on windows, only one option shows up, and the rest are just separators. I can still click on the options, but I don't know what they say except that I have memorized the ones I use.
I think I saw something similar at one point, probably because of a buggy version of GTK+. The page DJ mentioned ( http://lpg.ticalc.org/prj_tilp/win32.html) appears to be pointing to GTK+ 2.12.9, which is pretty old at this point. The current TILP installer is using 2.24.8. (I don't know why 2.24 would be crashing. Try uninstalling both TILP and any old GTK+ packages, and installing everything anew? There shouldn't be any 64-bit libraries involved, everything here is 32-bit except for the drivers.)
7
« on: April 21, 2013, 07:12:37 pm »
Really? So basically the only difference is that some BCalls and RAM areas moved to different addresses and the LCD stuff is different?
More or less, yeah. But just like BASIC programs, most assembly programs will need a lot of modifications to make the UI work properly on the larger screen. @FloppusMaximus what I guess you could do is wait until June then if by June there's no sign of an imminent SDK release, then start working on apps instead of waiting, in case you end up wasting your time with TI. Just take for example TI-Connect 4.0 Windows, where there were no sign of life for its release for a long while after the calc came out (although it eventually came out with no warning)
Yup. I guess we'll see what happens in the next couple of months. The main limiting factor, though, is always my free time. 
8
« on: April 21, 2013, 07:01:05 pm »
Do Basic Builder applications call B_CALL(_ReloadAppEntryVecs) before exiting? If not, I don't think it's an OS bug as much of a Basic Builder bug for not following TI's application exit protocol. I think it was recently noticed in a thread on Cemetech that one of the effects of not calling this (at least on MP OSes) is that the appRunning flag is left set when the application exits and small issues arise, so whether or not you mess around with context vectors and you think you actually need the call, it seems that this call may be important.
To be clear: if you don't change the context vectors, there is no point in calling ReloadAppEntryVecs (it won't hurt either.) If you do install custom app vectors, your putaway routine needs to B_CALL ReloadAppEntryVecs, and then either B_JUMP PutAway (recommended) or exit in some other way (not recommended, but seen in some example code from TI.) As a rule, a custom putaway routine should never 'ret'. (As a side issue, if your program's exit routine does its own cleanup, making the putaway routine unnecessary, you might also choose to call ReloadAppEntryVecs before JForceCmdNoChar. In most cases, though, it makes more sense to put all the cleanup code in the putaway routine, so it will be called regardless of which way you exit.)
9
« on: April 20, 2013, 05:43:01 pm »
Oh, I absolutely agree, don't wait to start writing great programs! But, assuming the SDK is released fairly soon, it'll be better if we can avoid using unofficial names and terminology, particularly in a program like Calcsys. In any case, there are still some serious issues that I need to deal with before it's usable, and at the moment I have two other TI-related projects (TilEm and TILP) that are a higher priority. As for app signing, the word is that RabbitSign should work just fine if you can arrange to have an appropriate certificate installed, or if somebody somehow managed to obtain the necessary private keys. With the current version of RabbitSign, you may have to manually specify the program type (since it doesn't recognize the .8ck extension or the 0F product code); I'm planning to release a new version of RabbitSign shortly that fixes those issues.
10
« on: April 19, 2013, 09:14:20 pm »
Yes, I meant an official SDK from TI; I've heard rumors that there will be one eventually.
11
« on: April 19, 2013, 08:30:12 pm »
I've been working on a port of Calcsys, but for the time being it's on the back burner as we wait for the SDK.
12
« on: April 19, 2013, 06:03:48 pm »
Indeed. The only way I've found to exit "panic mode" is to toggle STB on and off (maybe SLP would work as well.) I think this is the controller's way of saying it doesn't like what you're doing.
It seems that it does indeed have a resizing function, but it doesn't work reliably (sometimes it works correctly, sometimes it draws a few pixels and then panics. Something to do with timing, I guess.) I'm not sure exactly what all the resizing modes are doing, but all 7 modes are down-scaling. And when they do work, they apparently work by simple resampling (dropping pixels, not doing any sort of averaging), so it really is a basically useless feature.
13
« on: April 18, 2013, 09:36:48 pm »
I've just checked, switching to interlaced mode does not have any apparent effect on screenshots. The program you're using to switch the screen mode must be doing something else that interferes with screenshots.
14
« on: April 18, 2013, 06:15:45 pm »
Actually, for the wrapping around, I'm referring to having a window of (y1,y1+height-1) and (0,319). If you draw vertically, you'll wrap around after 319 (not undocumented at all). Ah yes, good point. However, from what I saw on the SVN, you may not be clipping LCD coordinates to 8-bits or 9-bits upon write. Any bits listed as 0 in the data sheet is forced to 0 (i.e. writes are ignored). This should be useful for some code optimizations, I think.
Ooh, excellent observation, you're right, I forgot to do that (although, for most of the registers, it shouldn't make any difference in practice.) This also suggests an obvious test for undocumented registers/bits, and indeed there are several: - R04 (undocumented on 9335) has the significant bits 0777. (On the 9325 this is the "resizing control" register and ought to have significant bits 0333. So maybe the 9335 allows resizing after all, and maybe it even has more modes than the 9325? On the 9221 this is one of the two comparison registers and should have significant bits 3F3F.) - R05 (as documented) has the significant bits 0003, though as I've noted elsewhere it doesn't seem to have the documented effect. (On the 9221 this is the other comparison register and should have significant bits 003F.) - R06 (not documented anywhere that I know of) has the significant bit 0001. - R10 has the significant bits 1717; according to the docs it should be 17F3. (edit: not true, it's just that reading registers doesn't work correctly when the STB bit is set.) - All of RE2-REF, RFE, and RFF have some significant bits; of these, only RE6 is documented.
15
« on: April 17, 2013, 11:25:21 pm »
TilEm does support 160x240 mode, yes. Most of the documented LCD controller features are supported at this point; some of the undocumented features still need to be tested. As far as sprite orientations are concerned: in most cases, you should be able to store the sprite in whatever orientation you like, and flip/rotate it by switching the output mode as desired. As for the case of wrapping around that calc84maniac mentions: that's one of the undocumented features I still need to explore.
|
Show Posts