MaxCoderz

nice work! Id just like to say that while PTI is tied with TilEm for my favorite emulator, it is constantly getting better. I still frequently get wierd garbage showing up in ways that never happen on my hardware calc....usually after quitting an App. for example the TI-OS homescreen cursor will start blinking down the screen behind the currently running program, even if its one thats known to be stable and never causes issues on my real calc. It also at one point managed to fry my ROM once into some sort of permanently reverse-split screen mode that my normal RAM clear couldn't fix.....is it normal for people to get bugs of this nature (I know its still under development) or am I the only one?

My guess for the split screen effect would be some garbage code accidentally modifying the Z-address of the LCD. That’s something that can happen on the real calc as well. Of course it’s often hard to tell whether a bug is caused by the emulator or the program emulated, but PTI is generally quite stable in its present state.

Im quite sure it isn't the program emulated as it never caused a problem on hardware, on in TilEm....Ill post a screenshot of the effect.


I get other things, usually similar to this, although sometime it appears while a program is running... and always after resetting the emulator the same program will work fine.

[edit]

also, what are the chances of being able to send .8xu updates to the emulated calc at some point in PTI's near future?

There’s little I can do about bugs that cannot be reproduced at will. As I said, they can be anywhere.

elfprince13 wrote:also, what are the chances of being able to send .8xu updates to the emulated calc at some point in PTI's near future?

I don’t think there’s anything in its way, at least I think I have the necessary file format description somewhere.

it reminds me of when the cursor goes 1 down every time it blinks and sometimes leave a character. Pressing Clear usually solves that.

It reminds me of when an app exits via ret instead of jforcecmdnochar. But if a ram clear fixes it, it does suggest that its cause by ram corruption. Clearing the save state and re-dumping the rom might be a good idea. If those fail, then its the stable app's fault.

Whats this program anyway?

Jim e wrote:It reminds me of when an app exits via ret instead of jforcecmdnochar. But if a ram clear fixes it, it does suggest that its cause by ram corruption. Clearing the save state and re-dumping the rom might be a good idea. If those fail, then its the stable app's fault.

Whats this program anyway?

I've had issues with MOS, COS, DCS, Graph3 and CelSheet (all the ones Ive used in PTI). it also seems to be a cumulative effect. like run the app once and its fine, run the app again and i get garbage, run the app again (if the calc is still usable) and I get a ram clear of some sort. I also get the garbage occuring in programs (which is annoying because then Im not sure if its my codes fault or PTIs....so I have to reset the calc and try again or test it on hardware, generally though the symptoms are pretty much the same--random blinking cursors, garbage on screen, memory dumps followed by random menus that reset the calc)

A little update. I added two pseudo-instructions that can be used for tracing the program. Both output some information to a new debug component, a simple text box. I’ll also make it possible to save the output into a file, because the text box can only hold a limited amount of information. Currently this means only the last 50 writes by either instruction.

I think pti_dump_registers is straightforward. The other, pti_printf is analogous to the good old printf, except dumber. You must point hl to the null terminated ‘format string’. The command escape character is backslash, and all the commands consist of a single character: An example format string could look like this in an assembler, assuming that it emits one backslash for two: I know this isn’t very useful in its present form, but it is rather meant as an inspiration for further ideas. Nothing is cast in stone.

Oh, goody! This is just the kind of thing that will make debugging so much easier. Unfortunately i dont have a whole lot of cosing time over the next week or so ... i will definately be working this into my testing routine. Thanks CoBB.

I added a short FAQ section to the project page. I recommend reading the answer to the second question.

Wow, I found a way to fix broken ROM images with PTI. Simply delete all your apps, which initiates a defragmentation. After this, you can apparently send archived files to the calc with no error.

So would that mean that your App loading technique isn't updating something (are you still 'force-loading' the Apss?) and does that imply that TI is keeping track of "something" via a checksum and/or table of these "somethings", and therefore needs to be fixed by defragmentation? What happens at a defragmentation?

If so, wonder what it is... so many questions....

I’m using the same force loading technique as TilEm, but when I was experimenting with sending apps normally through the link port, other areas of the flash were also updated (just a few bytes). It’s definitely something to look into...

Hey, I haven't messed with pti a lot yet 'cause I'm just starting to learn assembly, but I think it's pretty nice so far. I ran into an odd bug though, or maybe I messed something up, I open it, open the debugger, and the disassembly window is blank (the layer/frame/whatever doesn't even show in the outline). The only thing that loads in the debugger is the registers. I was wondering if maybe I'm doing something wrong, or if this is a bug.

Thanks for your time,
Papersnowman

Try clicking with left-button on your mouse on the empty window... that will "turn on" the calc afaik