Fw: Serial Flash Expander Proposition

[Prev][Next][Index][Thread]

Fw: Serial Flash Expander Proposition

Check it out!


----------
: From: Zenon Lynx <Zenon@bbs.nexes.com>
: To: List ZShell <list-zshell@lists.ticalc.org>
: Subject: Serial Flash Expander Proposition
: Date: October 9, 1996 6:07 PM
:
: Here's a new bunch of thoughts I have:
:
: We must find ways to run existing programs on the Serial Flash expander
so
: as to 1) retain compatibility with current programs and games and 2) so
: that the programmers can keep their current programming techniques.
Since
: ZShell is the one to locate where the programs are in memory, we should
: embed a program into ZShell 4.0 (it should be built into ZShell 4.5 if
: Magnus will participate willingly) so that it will search the external
: memory for the program when initiating.  Why the external memory?  We
: should use the internal memory for processing information and the
external
: memory for storage.  Only when we run out of internal RAM will we start
: swapping info between the chip and the extended RAM.  This is the same
: theory used in processing values in the Z80 registers versus processing
: information directly from memory unless necessary.  The programs remain
in
: memory though, and not in the registers.  All programs will be stored in
: external memory except ZShell, the interrupt handler and perhaps a
: defragmenter and a transfer program that transfers files from the
extender
: to another calc or another expander if Mel will help in producing this
: extra port.  So once you remove the expander, there should be nothing
: except for those items in memory.  Also, there should be support for
calcs
: turboed using a 1pf capacitor (3.0 times faster) and using no capacitor
: (3.5 times faster). There have been errors trying to play games and such
: through ZShell linked to another calc, both being turboed.  We need to
fix
: this problem.  Also, we need to be able to put any variable into the
: extended memory using the same interrupt handler that will stay resident
in
: memory.  Using this idea, there will be much fragmentation and
: disorganization in the calc, perhaps slowing it down.  In this instance,
: the defragmentation program and a file organization program are
mandatory.
: With this in mind, making the extender accessible to all resources and
: functions are essential (ie. the solver, constants, ect.).  Using this
idea
: we must find a way to intercept all calls to RAM (calls to ROM must stay
or
: the TI won't operate!  But after the ROM calls are completed, all values
: must return to the interrupt handler to be further processed) and
redirect
: it to the interrupt handler to find the variable in ectended memory.  The
: interrupt handler must also be able to tell if the value being
transftered
: is to be used in the program in internal RAM or external RAM (where
: programs bigger thanb 28.5Kb must overflow into) to know where to be
: processed.  Naturally, TI-85s without the extender will not be able to
: operate these programs.  Another thing this brings into mind is that
there
: should be ZShell support for normal TI-85s.  There should be a ZShell
4.5SE
: (special edition) for people with RAM expanders and a ZShell 4.5 for
normal
: calcs.  This other version will not contain the interrupt handler,
: therefore, allowing all RAM calls and programs to be operated in internal
: memory.  This is why the programs themselves must not refer to an
interrupt
: handler besides compatibility and programming problems.  The ZShell 4.5SE
: will not work on the normal TI-85 (or will, but then it will constantly
be
: asking for you to secure the link cable or to press enter when the
expander
: is ready...or just crash).  SE must absolutely have Turbo calc support.
: Back to the current topic.  Only RAM calls with a specific signature made
: by memory system essential programs may access the internal RAM like the
: defragmenter, the interrupt handler and any other program in this class.
: These programs must remain in internal memory else they will be affected
: while running, which would be risky when the program changes locations of
: items in the external RAM (ZShell may not be able to find it again,
: crashing).  We also need software to reformat the memory (RESET) from the
: computer (or the calc, but you'd load it in only when you want it; else
it
: could get careless...).  This way it wouldn't be time wasting trying to
: delete everything from the extended RAM.  On the extended memory, we
should
: not partition it out into more than one section since it would be dumb if
: you ran out of space in the strings section while you want to put another
: ZShell program in but you have 200kb left in your pics section!  There
can
: be a utility like that for people who want organized memory, but then the
: file manager and the interrupt handler would have to be changed to
: accomodate different sections of memory.  We will need the interrupt
: handler to detect if the RAM is 1MB or 512Kb, and later, if we can
attatch
: two extenders together, 2MB and up.  The interrupt handler should be able
: to control the situation whatever the case (sort of like if you have more
: space, all it needs to do is "add more words to its vocab").  We will
need
: other programs like "Space left" and programs that tell us how much free
: RAM a program needs to use to process (like XC, but in this case it could
: go beyond 28.5Kb).  This way, the calc won't crash (it comes up everytime
: you don't have enough free RAM to run something).  Anyways, sorry if this
: is a little long and messy...I'm just jotting down ideas as fast as they
: can come.
:
: If you have any comments or questions dealing related to logical IDEAS
(not
: illogical ones or questions and comments dealing with software or
: hardware...that's not my field) please e-mail the list referring to
"Zenon"
: so that all of us can hear you out!
:
: "Canada has no national identity other than our strongest policy:
: multiculturalism"
: -= Zenon@bbs.nexes.com =-