*bumpity bump* Bug report:


Code:

I got surprised with that.
Never thought it was a feature from TI that caused the bug in emulators.

Did buckeye resolved? Better cross post in Revsoft, maybe?

Actually, shortly after I made that post, BrandonW said on IRC that it was a bad idea to do that emulator-side, and it would be better to make a small ASM program to do that instead. It's apparently a longstanding item on his todo list. Buckeye also addressed the bug I mentioned in my latest post, so he had known about that.

That leaves me to wonder why the pages don't have the correct value to begin with in the emulator?

A good question. BrandonW mentioned that it had something to do with how the certificate page is dumped from a real calc, although don't quote me on that in case I'm misremembering. Hopefully BrandonW will drop by and explain it; he hasn't popped up at all in the last week or two.

Well what the emulator does is 'forceload' the app, meaning that rather than sending it over the link port and letting the OS routines do the work, it takes the data itself and writes it directly to the flash page. The reason for this is that sending a large app takes forever over the normal link port (if you want to try it, reset all memory on the emulator then load an app, it will use the OS routines). Forceloading also has the benefit of being very handy for testing. Say you have some code that is on another page of your app, or data that you want to change. Rather than having to quit back to the OS, you can simply load the data with the app still running and see the changes almost immediately

tl;dr if you use the real os routines, the app is marked as not a trial, but we dont use them because the link port is slow

It always looks to me like you're setting the calculator into unlimited-speed execution mode when I'm transferring in an app; how bad would it be to just send via I/O with the calculator unlimited with regards to speed? What if you toggled that based on how fast the emulator was able to go without the limiter?

Or you could have an option whether to force-load it, send it, or do the faster one.

Indeed, that sounds good to me.

automagic behavior would be bad in this case, since it would appear inconsistent to the user.

Overall, the benefits far outweigh the negative effects. The plan was always to add an option to disable forceloading, it was just never implemented. And once I figure out what the correct offset in the certificate is, it will be implemented, trust me

Excellent, very happy to hear it. I've had several cases where I was building a precarious testbed to figure out the source of the bug, only to have Doors CS invalidated when switching into Editor mode and crashing the calculator. @Elfprince: What if there was a checkbox to switch between forceloading and automagical detection? Or even a set of radio buttons to choose always forceload, always load normally, or automagic?

Code:


Solved and uploaded

Huzzah! Is this both versions, or just the Visual Studio one?

currently only the gcc version (which is the default)

Oh goodie, I like that one better anyway. I'll grab it right now.

*bump* I have a bit of a bone to pick with you. The latest build neither updates the register display when single-stepping in the debugger view, nor goes particularly fast (and seems to have slowed down a lot).

Edit: Thanks, your fix did the trick. I'm also looking forward to this tab idea of yours. Sidebar, any chance of maintaining the position in the memory view between closing and reopening the debugger window?

That would probably be a good solution.

Agreed, but it looks like he already solved it out with no need to do this. Come to think of it, I think I've still had Doors CS disappear every fifteen executions or so...

For now I'm going to leave it so that the only way you can load normally is by resetting all memory and then loading the app. I think I may have found why dcs still disappears, 10 bucks says you're on boot 1.02 rom? Also betting on OS 2.53 MP