Re: A85: Features for a new shell
[Prev][Next][Index][Thread]
Re: A85: Features for a new shell
hahaha. you fool. you think adding usgard or zshell support would be hard?
BASIC would be 5000 times as hard as either.
*snort in contempt*
in my opinion, due to the basic lack of programming interest right now on
the 85 (and the little there is is for Usgard--deal with it) any shell
programming is just for the experience of writing a shell. the dh85 shell
(dh85.ticalc.org) is an os, (not multitasking though) and i have basically
decided that if any further work goes on, all usgard/zshell support will be
dropped. im skinnying it way up.
--kaus
----- Original Message -----
From: <Farid76@aol.com>
To: <assembly-85@lists.ticalc.org>
Sent: Thursday, February 24, 2000 3:16 PM
Subject: Re: A85: Features for a new shell
>
> 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
> libraries, I will first put a lot of functions in the shell itself to make
> programing easier. After that, maybe ...
>
> I have some questions about the way the shell should handle
multitasking.
> 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
>
>
References: