Reviving the Vera project!

A forum where you can announce your awesome project(s).

Moderator: MaxCoderz Staff

User avatar
Jim e
Calc King
Posts: 2457
Joined: Sun 26 Dec, 2004 5:27 am
Location: SXIOPO = Infinite lives for both players
Contact:

Post by Jim e »

Timendus wrote:@Jim: What do you mean by a "false read"?
The keyboard is set up in a matrix, and it detects based on what row is set when a group is allowed to return a keypress. Because of the grid layout if you press 3 or more keys, you can't be garunteed that all keys being pressed are actually being pressed.

For example if you press 8, 5, and 6 then 9 will automatically register as being pressed as well. 7, 1 and 3 would also show 9 as being pressed. ON doesn't suffer from that, its by itself.

We're pretty lucky if you think about it, the most common keys for gaming don't over lap.
Image
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

Timendus wrote:@Jim: What do you mean by a "false read"? I'll agree that using the ON interrupt for those things makes sense, but they could just as well have been consistent in using Clear or Del as a break key, in fact that would probably make for a less complex implementation. We see people doing that in assembly applications all the time.
Using clear/del as a break key requires polling the keypad to see if it has been pressed. Since the ON key generates an interrupt, there is no need for polling so a program can be broken at any point - not just when it is polling the keypad.

This could be useful if a program gets stuck in an infinite loop, for example.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

I understand that, but then you'd have to do some serious stack magic to kill the program, or else you'd use some kind of flag and the program has to poll the flag; same problem.

Would it be something like

Code: Select all

ld hl,safeExit
call interrupt_register_break

; Dangerous code with stack shit and everything B-/

safeExit:
ret
and then have interrupt_register_break store the current stack pointer somewhere safe, and if you press ON it'll restore the stack and jump to safeExit? We could do that, I guess :) Then we'd have a way to kill assembly programs, if they register themselves properly. Or we could let the kernel do that, to be on the safe side.

I suppose we should add a little dialog then; "Kill application or turn off calculator?". We could also put the application switching in that dialog... hmmm, this could be fun :)
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

Timendus wrote:I suppose we should add a little dialog then; "Kill application or turn off calculator?". We could also put the application switching in that dialog... hmmm, this could be fun :)
You could also check to see if 2nd (or some other key) is pressed and use 2nd+ON as the break code.

I wish I had a good excuse to code something like that! :D

EDIT: You could also steal the register dump code from the debugging library I did a while back. Or use it in a kernel_panic routine for when things go haywire.

There are some interesting possibilities.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

My God, I totally missed that thread! Awesome snippets! :)

Anyway, using key combinations could be a better idea, because our console code isn't uhm... shall we call it "thread safe"*? :) I've just been playing with adding a menu, but of course it screws up the screen (which is fine if you kill the app, but not so fine if you just shut down and turn it back on).

*) What I mean is that all our display code can use a variable image buffer to work on, but the console code has one buffer hardcoded. That's a bad idea if we want to enable application switching, so we'll have to fix that somehow anyway.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

Ah, forgot to post here that it's been implemented. If applications (or the kernel, before it launches an application) register a safe exit routine and a stack pointer by calling interrupt_register_break, you can kill the application at all times by holding Enter and pressing the ON key. This should add a bit of safety on the kernel level.

My demo of this is pretty stupid; it just jumps head first into an endless loop that it can't come out of, and you have to kill it with the key combination. Works like a charm.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
Art_of_camelot
Regular Member
Posts: 124
Joined: Sun 09 Sep, 2007 8:50 pm
Location: The dark side of the moon
Contact:

Post by Art_of_camelot »

So this means ASM programs can be broken without crashing the calc? If so that is very nice. :D
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Art_of_camelot wrote:So this means ASM programs can be broken without crashing the calc? If so that is very nice. :D
Only with infinite (or very long) loops. There is no practical way to prevent people from writing to locations they should not be doing with the hardware we have available to us.

Not that such a feature isn't useless, of course!
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

Exactly, you can break programs if they get stuck, but it still doesn't prevent them from screwing up the RAM, which can also crash your calculator. Any ideas on how we can prevent that, apart from working with different hardware? ;)
Not that such a feature isn't useless, of course!
I suppose you meant "useful"? :mrgreen:
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
GuillaumeH
Regular Member
Posts: 143
Joined: Fri 17 Dec, 2004 8:30 pm
Contact:

Post by GuillaumeH »

Marc Plouhinec (the author of SNG) told me once that he had a solution for this problem. He executed a small interrupt program that checked if the PC of the currently running program was not in a "forbidden" area, and stopped that program if it was the case. I guess this is the most reliable solution we can have with this hardware.
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Timendus wrote:I suppose you meant "useful"? :mrgreen:
No idea what I was going on about. :D It's a useful feature, yes.

The only viable software solution would be to use an interrupt handler to check the state of the program counter, as GuillaumeH described. It's still not ideal, though. Interestingly TI did implement a partial hardware solution in the infamous ~8.8K barrier.

Really, the only practical way to get around this without hardware modification is via managed software.
CoBB
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

benryves wrote:The only viable software solution would be to use an interrupt handler to check the state of the program counter, as GuillaumeH described.
Well, if you set the interrupt to the highest speed, you can regain control about once in 1000-2000 instructions (10-11k cc). That might catch some nastiness, but you can’t be sure about the corruption it made. On the other hand, there’s no way to protect against erroneous writes caused by bad pointers used by the right code, unless we use the paging mechanism to our advantage (accidental paging requests are unlikely), and provide a whole RAM page solely to the current application. That’s not much help for the regular plus, of course...
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

That's exactely what I was thinking... If the problem you're trying to catch is accidentally executing random data, then an interrupt isn't going to help you. You'd have executed at least a few thousand malformed "instructions" before it gets detected. Also, it doesn't prevent applications from screwing up RAM because of programming errors. In short, it doesn't really do anything, in my opinion.

We can however keep an eye on sp, as that usually doesn't change as quickly, to monitor that it doesn't move into allocatable space (overwriting the stack because you think it's your memory = bad). Even then, we'd need to keep a margin, and even then we'd not be able to catch with certainty a routine that just keeps pushing data on the stack from screwing things up.

Also, we can use the $C000 barier Ben mentioned to our advantage, and store data after it. Swapping RAM pages isn't an option if we want to support the regular Ti-83+, though it could be a nice extention for newer calculators.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

Timendus wrote:Any ideas on how we can prevent that, apart from working with different hardware? ;)
Don't release buggy software. :mrgreen:
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
CoBB
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

qarnos wrote:Don't release buggy software. :mrgreen:
And then comes the deeply philosophical question whether something is a bug or a feature. ;)
Post Reply