Re: SD: Shells on the 83+
[Prev][Next][Index][Thread]
Re: SD: Shells on the 83+
OK, first of all, having to allocate data space at the end of every program would be a hassle for most programmers,
which means that you wouldn't get very many supporters for your shell. Secondly, you'd also have to convince every
programmer not to use direct screen writes and make your shell control all of that instead. So a program would call your
display function, and if it is the current foreground process, the shell will update the screen from graphbuf. Your
shell will also have to wait for the display routine to finish before switching to another task. It is possible, but it
would be very messy to implement. You'd also have to rewrite the handful of programs that use direct screen writes
(SQRXZ comes to mind, and possibly Galaxian?).
----- Original Message -----
From: "Robin Kay" <kaypictures@clara.net>
To: <shell-developers@lists.ticalc.org>
Sent: Monday, January 31, 2000 16:14
Subject: Re: SD: Shells on the 83+
People on the A83 list are more pessimistic but anyway... Programs wouldn't use
all these different "saferam" areas, the would have a data space allocated at
the the end of their code. Code accessing the hardware directly would have to
disable interrupts first. After certain ROM calls you would have to IM 2 / EI.
This reduces what has to be backed up to Assembly Flags, OPx, Stack, and Graph
Buffer*, just under 1.5kb. I scrapped the complex event model becuase it's too
slow.
* I wouldn't back up the Screen, just copy the contents of the Graph Buffer onto
the screen when the process is restored. The Graph Buffer is mainly used to
prevent the flickering cuased by direct screen writes, so the effects of this
will be negligable (as long as programs don't use direct screen writes).
--Robin Kay--
<snip>
Follow-Ups:
References: