Re: SD: Shells on the 83+


[Prev][Index][Thread]

Re: SD: Shells on the 83+




Making a shell which enables multitasking does sound like a good idea at
first, but there are lots of problems. Let me mention a few of them:

The following things need to be backed up:
- Mem areas such as GRAPH_MEM, APD_BUF, TEXT_MEM, TEXT_MEM2, OPx, ...
- System mem
- All registers
- The state of the display controller and the contents of its memory
(Thats almost 3k per program)

If any of the programs uses external programs, some system which updates all
pointers used in other programs which are currently running needs to be
implemented.

And all programs would need to be rewritten to support this.

Event/IPC model:
- Some ROM calls disables interrupts, so if these are called this will
disble timers etc.
- The programs handling the interrupts might move around in mem, and in the
interrupt routine one can not assume that the VAT is correct.

If you take all the above into account, it id oppvius that a shell like the
one you are suggesting would need to limit what parts of the calc the
programs can use.

The shell would thus be slower (background proc), the programs would be
slower (can not use text mem), would need more free RAM (to backup every
thing)...

Dines
----------------------------------------------------------------------
 Dines Justesen
 "The fact that no one understands you doesn't mean you're an artist"
 dines@aub.dk
 www.student.dtu.dk/~c958362
----------------------------------------------------------------------

----- Original Message -----
From: "Robin Kay" <kaypictures@clara.net>
To: <shell-developers@lists.ticalc.org>
Sent: Monday, January 31, 2000 4:51 PM
Subject: Re: SD: Shells on the 83+


>
> Members of the A83 mailing list have echoed your concerns about the
feasability
> of some of the ideas, and their neccesisity. The message I posted was not
ment to
> be a specification, but mearly a collection of ideas. I understand that
programs
> would have to be specifically written for it, here are the restrictions:-
>
> * Programs cannot use interrupts
> * Programs cannot use saferam areas, must use the external data space.
> * Prograas must compensate for relocation if indexed addressing is being
used.
>
> I intend for this project to be educational, and I will do it for the sake
of
> doing it and for what I might learn from it. :-)
>
> --Robin Kay--
>
> ADAMMAN106@aol.com wrote:
>
> > I don't own an 83+, but I'd like to comment on your rather extravagant
idea:
> > The idea of multitasking on a calculator is very intriguing.  However,
I'm
> > not sure of the feasabilty of such an idea, or to what extent it has
ever
> > been tried before.
> > I think that a system could be designed to allow useful task switching
> > considering the capabilities of any of the flash-based calculators.  It
would
> > require, however, that programs be specifically designed to facilitate
it.
> > Standards would need to be established.  You would need to do a VERY
good job
> > on this, so people would accept it.  The main problem with this is the
very
> > low-level nature of asm - most programs are made to take full advantage
of
> > the calculator's cababilities.  Since it's unpredictable what memory
usage
> > goes on in a typical asm program, no ordinary programs could be
multitasked.
> > You would actually need to create your own system of relocating
programs,
> > starting them etc and completely disregard what TI has already done.  I
think
> > it is possible, but will be very difficult to do.  And then if nobody
likes
> > your ideas all that work will be for nothing because nobody will develop
for
> > your shell.
> > Some of your other ideas seem a bit extreme, some unnecessary.  I feel
that
> > taskswitching will be a very successful thing on calculators in the
future.
> >
> > ~Adamman
> >
> > In a message dated 1/30/2000 6:04:21 PM Eastern Standard Time,
> > kaypictures@clara.net writes:
> >
> > >      Since it came on the market, Ion and recently the Ion-compatible
> > >  Ice have been the only shells for the TI-83 Plus. I belive Ion was
very
> > >  useful becuase it allowed the far more common 83 programmers to
easily
> > >  bring their games and programes to the 83+ platfrom, it bridged the
gap
> > >  between the two systems. I belive the usefulness of Ion's portability
> > >  will gradually decrease as more people get 83+'s and there are more
83+
> > >  prgrammers, though this is of course purely my opinion. Here are some
> > >  ideas for a new shell for the 83+.
> > >
> > >       Task Switching - Based on my experience with lightweight
> > >  multi-threading on the PC, this shouldn't be too difficult to
implement
> > >  (Note: I'm talking about Real Mode, not protected mode register bank
> > >  switching). The Timer interrupt could be used to pole the keyboard
for a
> > >  certain key press combo, when this happens the interrput handler
simple
> > >  loads the stack pointer with the address of different program's stack
> > >  space and when the interrupt returns it will load up the other
programs
> > >  registers and program counter. The handler would also have to
preserve
> > >  and restore the screen. Also, providing the program didn't screw up
to
> > >  badly the task switcher would allow a kind of crash protection.
> > >
> > >       Event/IPC Model - Since the shell uses the interrupts it should
> > >  provide applications with the ability to load event handlers to keep
> > >  track of what going on. For example, an event handler dealing with
link
> > >  port could run a background file transfer while another application
is
> > >  running. The way I see this working is libraries being the event
> > >  handlers. Once a library is loaded, the system makes calls into it to
> > >  notify it of events (ie. timer), and programs make calls into it to
> > >  check it's status. For example, a mouse library would be notified on
the
> > >  timer event and it would check if the current program had enabled it,
> > >  then if so it would check the key pad arrows to see if the mouse had
> > >  been moved and then update the display. Programs could then call the
> > >  mouse handler to check it's position, if it had been clicked, etc.
Event
> > >  handlers that were not notified of any events would be libraries in
the
> > >  traditional sense. While this might be quite slow it would be a very
> > >  powerful feature, and at least it would very interesting if only for
the
> > >  educational value.
> > >
> > >       Public Data Manager - Programs that save data (ie. hiscores)
into
> > >  their program file irritate my hugely. It was a great on concept on
the
> > >  83 when their was no archive but it is a real pain on the plus. When
you
> > >  are constantly moving programs from the archive it presents two
problems
> > >  a) If you want to preserve this data you have to regroup the program
in
> > >  archive, b) In the case of hiscores most programs don't let you reset
> > >  it, so you have to re-unarchive the program or re-obtain it via graph
> > >  link to reset it. A public data manager would keep a key & value
table
> > >  of data (think java.utils.Hashtable) which would be stored externally
in
> > >  an AppVar. Even if you deleted the program from RAM you would retain
the
> > >  data and if you wanted to remove the data you could clear the entry
from
> > >  the PDM.
> > >
> > >       Virtual Directory Structure - The PDM could be used to store
> > >  records for each program program, saying what directory it is in.
Thus
> > >  programs could be placed in folders, and I've just illustrated
another
> > >  use for the PDM. I think there is a module for Ion that does this but
> > >  I'm not sure.
> > >
> > >       Additional Archive Space - The 83+ has areas of the archive
space
> > >  that are reserved for Applications (64Kb). Theoretically this space
> > >  could be used to store data (ie. more programs), this woudn't need TI
> > >  signing becuase you're not running the program from the archive.
There
> > >  might be problem if TI-OS does some kind of validity check of the
> > >  archive on start-up, it might declare the archive invalid and clear
it
> > >  but I don't know.
> > >
> > >       This new kind of shell would allow a fundimental change in the
way
> > >  the 83+ is used. From what I gather people use the 83+ as if it was
an
> > >  83, just using the archive space as a backup storage area. RAM should
be
> > >  used more as temporary storage area and the FLASH-ROM more as the
> > >  hard-disk. Thus programs are stored in the FLASH-ROM and reallocated
> > >  into the RAM when needed, with the PDM used to store data. If my idea
> > >  about extra archive space is valid then the archive space can be
> > >  extended from 160KB to 224KB (according to TIs FLASH-ROM page usage
map
> > >  in the SDK). This new shell will undoubtedly be bigger than Ion, but
> > >  with a shift toward using the FLASH-ROM as the main storage area the
> > >  amount of RAM space will become less important. Becuase of the
> > >  background processing it will also be a bit slower, but I still think
> > >  the advantages outway the problems. If you want to use multi-tasking
> > >  you're are more likely to be switching between your peridoic table
and
> > >  the game of Tertis you're playing on the side, than between two fast
> > >  paced action games. Emulators to perform the lower level functions of
> > >  the calculator (ie. Maths) within the multi-tasking enviroment will
be
> > >  important and useful, perhaps an emulator of a simpler calculator
would
> > >  also be useful . For example you caould emualte a normal "desk"
> > >  calculator as I often find it's easier to perform simple calculations
> > >  with a simpler calculator (and it would be smaller and simpler to
> > >  program).
> > >       Well, I'm finished with preaching about great the 83+ is and so
I'm
> > >  going to go off and try writting a program to demonstrate lightweight
> > >  multi-threading. However I still don't understand enough about
> > >  reallocation to try and write that part of it. Program's origins are
set
> > >  at 9327h, either when a program is run it is copied to that address
in
> > >  memory before it is run or any instructions in the program that use
> > >  absolute addressing are changed at runtime to reflect it's location
in
> > >  memory. Obviously only the second system would work in a multitasking
> > >  system, and first system would waste 8k of RAM. Has anyone got any
more
> > >  precise details on how Ion and TI-OS handle relocation? Please reply
to
> > >  the suggestion with you opinions... Note that this is being
cross-posted
> > >  (Uck! I know...) to both the Shell Developers mailing list and the
A83
> > >  mailing list so please keep this in mind when posting your reply. If
> > >  anyone is interested in collaborating on then please contact me at
> > >  robin@paradoxmm.com, only use this address (kaypictures@clara.net)
for
> > >  private e-mail when the other one is down (Their are complex reason
for
> > >  this... I have an address for mailing lists and I get so many e-mails
on
> > >  it that I ocassionally miss one...  etc... etc...). Is this shell a
good
> > >  idea?? Please reply!!
> > >
> > >  --Robin Kay--
> > >
> > >  PS: Does anyone know what .db $BB,$6D does at the beginning of the
Ion
> > >  header?
> > >  PPS: I think TSE (Task Switching Enviroment) is good name for this
> > >  shell? Opinions?
>
>



References: