Re: A85: Features for a new shell

[Prev][Next][Index][Thread]

Re: A85: Features for a new shell


In a message dated 2/24/00 2:17:19 PM Mountain Standard Time, Farid76@aol.com 
writes:

>     I will try to add support for BASIC programs to my shell, but for 
Usgard 
>  and ZShell I think I'd rather not to do so. It will increase the size of 
the 
>  shell, and anyway, only programs written for the new shell can be run in 
>  multitasking mode. But the relocation will be the same as Usgard. 
Concerning 

Leaving out support for Usgard, in my opinion, is a big mistake.  Usgard is 
now the predominant shell on the TI-85; I'm fairly sure there are more Usgard 
programs than even ZShell programs (at least more *quality* Usgard programs). 
 If your shell lacks Usgard compatibility, I have a very hard time believing 
it's going to catch on at all...

I mean, look at Rigel.  Rigel's an excellent shell that, in my opinion, is 
superior to Usgard, yet never caught on cause Usgard came out first and Rigel 
didn't support Usgard.

>  libraries, I will first put a lot of functions in the shell itself to make 
>  programing easier. After that, maybe ...

But putting a lot of functions in the shell itself would make the shell 
bigger, wouldn't it?

>      I have some questions about the way the shell should handle 
multitasking.

I'm not even sure multitasking is a good idea for as simple a processor as a 
Z80.  Prosit, which is a *task-switcher*, is the closest thing to 
multitasking of any TI calculator, and it's for an M68K calc.  I think the 
memory on the 85 is simply just too tiny to multitask effectively, if at all.

Besides, what multitasking applications could actually be of use on the 85?

>  But first, a little description of the system...
>  
>  There will be 2 kinds of programs: real mode and protected mode. Programs 
> for 
>  the real mode will run like in other shells, and programs for protected 
mode 
> 
>  will run in multitasking mode. Obviously, there is restrictions to 
protected 
> 
>  mode:
>  
>      - Programs can't use areas of memory like GRAPH_MEM or TEXT_MEM, so 
the 
>  shell create a safe area and return a pointer for each program.
>  
>      - When the user switch between the different programs running, the 
>  program which is given focus must update the screen.
>  
>  I have imagined 2 solutions to this last problem. The first consists of 
>  saving the whole screen for each program (bad idea for a 28 Kb RAM), and 
the 
> 
>  second would be creating a function in each program to redraw the screen 
> when 
>  the OS call it.
>  
>  If you have a better solution or if you know other problems implied by 
>  multitasking, please report it. I'm waiting for your feedback...
>  
>  Farid Bouzaghti

I'm not even sure what you mean by "multitasking" anymore...  Do you plan on 
doing a Windows-style multitasking with windows, or what?  I'm not versed 
much at all with multitasking, but I'd think the "tasking" part would be 
controlled by an interrupt, which would control what particular program is 
running between interrupts...which means you'd literally have to save the 
state of the program so that you can restore the exact state when you switch 
back to the program.  This would have to include temporary memory, the video 
memory, all registers, flags, the stack, the SP, the PC, maybe even the 
ports, etc., etc., etc.  I'm not sure how you'd do multitasking any other 
way, but you have another idea in mind, I'd like to hear it...

JayEll