LZ: Serial Flash Expander Proposition

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

LZ: Serial Flash Expander Proposition

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 =-
Follow-Ups: