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