Yuku free message boards

And one thing I should have warned about: if you interrupt a program between a HeapDeref on an unlocked handle and access to that handle, the calculator will very probably crash! (I never had VTI crash because of this while testing (I only tested on VTI), but it can theoretically happen. Ideally, programs would always lock a handle when accessing it, but unfortunately it is not always done.)

And I have discovered a bug: turning the calculator off (for example, when the APD kicks in in Backgammon) and on again will immediately reset the calculator. This is because [ON] is triggering a task switch which makes the memory check in the trap #4 fail. I need to hook the trap #4 to keep this from happening.

Found another bug: on the real calculator, the [ON] keypress is still detected by ngetchx and the like (actually, now that I think of it: it actually happens on VTI too). (I intended to wait for [ON] to be released before switching tasks, but I somehow forgot about that.)

But with enough free RAM, Backgammon and TI-Mahjongg run fine.

Maybe the sound problem is because the AI5 frequency is currently not part of the process context?

Unfortunately cr*p like the automatic reset is to be expected in the current state of the program. The problem is that I have no idea why that happened in your case.

With most kernel-based programs, it isn't any easier (and I am not sure my task switcher will work with kernel-based programs, I have not tried). But I often heard programmers claim you'd need to use special reentrant and hardware-abstracting libraries such as the ones used by Prosit instead of ROM_CALLs.

Hmmm...
The only problem is that it is slooow to obtain the correct value to write back into 0x600017. I need to wait for the next AI5 to occur for the value to be reset. (Will it even reset while interrupts are masked out? I'll have to try. Otherwise, I'll need to unmask AI5.) But it is doable.

So here is my current list of things to add to the process context:
* 0x600015 and 0x600017 (AI5 frequency)
* 0x600010 (HW1 physical LCD port)
* EV_handler, EV_hook
* Line 1111 Emulator hook (otherwise, programs using incomplete custom F-Line emulators won't cooperate with programs using F-Line jumps as supported by AMS >=2.05 and TIGCC >=0.95)
* 0x600018 (keyboard mask)
This will only take 18 extra bytes in the process context.

Quote:

---

2. Your program is not a multitasking program but a task switcher. It is a lot easier (and more usefull on Ti too).

---

I know it is not true multitasking. But the goal was to show that multitasking is possible: using the same technique for multitasking is as easy as using auto-int 1 or 5 instead of auto-int 6. That way, my task switching interrupt would become a true (round-robin) scheduler. Of course, this wouldn't be of much use without a centralized screen drawing and key reading system because the screen contents would change all the time and giving key input to the correct program would be close to impossible. And the handle locking problem would also become much more likely to occur with a huge number of switches. And last but not least, programs love to redirect those timer interrupts because their AMS implementation changes the keyboard mask. That's why I decided to do manual task switching rather than true multitasking.

Quote:

---

4. Why don't you lock all handles when you switch ? It will ve a lot safier. Every sym are unsecured (If you use SYM_ENTRY *).

---

Because this will make the memory requirements even worse (by fragmenting memory).

Quote:

---

5. Can't you save 30K of memory ? Here you have the current context (AMS global vars and IO) and 2 contexts. I think you should be able to do it with the current context and 1 memorised context.

---

Hmmm, this might be possible.

Quote:

---

6. Does it work with EndLess loop in FLash Rom (like ngetchx/GKeyIn/EV_eventoop) ?

---

No.
It works with Backgammon because my main keyboard reading loop is not ngetchx but a wrapper which calls kbhit and ngetchx, and does other stuff such as APD and low power mode.

Quote:

---

7. Does it work with programs which need ON key ?

---

No. If they read it using AMS key input routines, they won't get the keypress at all (at least they shouldn't - see the bug mentioned a few posts higher). If they redirect AI6, they will completely mess up the task switcher. But redirecting AI6 is a bad idea anyway, as it will also disable the [ESC]+[ON] in PreOs or KerNO.

Quote:

---

8. I think there will be som problems with temp folders .

---

I didn't have any problems in my tests. But I think the programs I tested with didn't use temp folders at all.


By the way, I wonder whether I should add the values of some of all of the AMS timers to the process contexts. For example, for APD, this is probably not a good idea, but for USER_TIMER, it probably is.