Re: SD: Shells on the 83+
[Prev][Next][Index][Thread]
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: