Re: SD: Shells on the 83+

[Next][Index][Thread]

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--

Dines Justesen wrote:

> 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?
> >
> >
Follow-Ups: References: