Re: LZ: Serial Flash Expander Proposition
[Prev][Next][Index][Thread]
Re: LZ: Serial Flash Expander Proposition
On Wed, 9 Oct 1996 18:07:12 -0600, you wrote:
>
>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. =20
Actually, I was already planning on doing this. You really don't need
zshell to support the expander. All you have to do is make a
second-level shell, one that you start in zshell, and this could
handle on-the-fly variable location and running. You wouldn't need to
mess with interrupts or fragmentation or anything else, it would just
be an extention of zshell.=20
>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. =20
The only problem I forsee is that the turboed calc will be too fast
for the expander. However, if I can adjust the timing capacitor just
right, you should be able to use a turboed calc without any expander
software modification. If it does prove to be a problem, I'll just
slow down the send and receive routines and make it a selectable
option in the program. =20
The way I planned it, you could operate the expander synchronously,
but due the the "race" problem and its subsequent solution, fully
synchronous operation is no longer possible. It won't make much
difference to the user, however.
> 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.=20
>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. =20
You probably won't need to deal with anything you just mentioned. The
process of redirecting any ram access to the expander would not only
be extremely complex, but slow, too. The solution is just to have the
secondary shell load and unload programs into a free slot of memory.
The shell would actually be pretty easy to design. The only problem
would be running programs that exit and then use interrupts, but most
programs don't do that.
> 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. =20
I doubt Magnus would want to do this, and it won't be necessary
anyways.
>if we can attatch
>two extenders together, 2MB and up. =20
It's pretty much impossible to connect two expanders simultaneously.
>We will need the interrupt
>handler to detect if the RAM is 1MB or 512Kb=20
This can be done using the get status function (you might want to read
the chip's data sheet, it explains everything). =20
This chip is really unlike anything else I've seen. It's not like a
hard or tape drive, and it's definitely not like other solid state
memory devices. Pretty much anything and everything you described is
possible without any complicated software, and besides, I plan on
writing them all anyways. =20
I don't think we should go about messing with the fixed RAM variable
locations, 28k or so is good enough. In fact, the only thing the
zshell community needs to worry about is creating applications that
actually take advantage of the extra storage. I'll soon release
routines that will allow you to access the expander, as well as a
detailed description of the file structure I plan on using (it's a
cluster type structure, so it's a bit confusing). In terms of making
a whole other OS that supports the expander, you can write it if you
want, but it's really unnecessary.
-Mel
<pre>
--
The TI-85 Memory Expansion Homepage
http://pilot.msu.edu/user/tsaimelv/expander.htm
</pre>
References: