[A83] Re: extra storage


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

[A83] Re: extra storage



I figure that interrupts could be used effectively for this purpose.  When 
you would want to recieve a file from storage, just hold down a certain 
combination of keys (why not 2nd-link?) and the interrupt program would 
fire.  Why not install an interrupt program in $9872.  Joe Pemberton claims 
that this is 768 bytes of RAM intended for ASM programs (for the 83 and the 
83+???) and 256 (NOT 257 - see my next post) bytes would be used for the 
mode 2 interrupt table.  This leaves around 512 bytes for a driver / browser 
program, etc, even a simple shell that could copy and run programs from 
flash.

In summary, the way to obtain files from the external memory doesnt have to 
take up program ram and the external memory itself can be relatively dumb, 
simplifying design.

Jeff


>From: Gavin Olson <gtolson@comcast.net>
>Reply-To: assembly-83@lists.ticalc.org
>To: assembly-83@lists.ticalc.org
>Subject: [A83] Re: extra storage
>Date: Tue, 17 Dec 2002 17:17:06 -0500
>
>At 10:43 PM 12/17/2002 +0100, you wrote:
>> > A driver program would work for the storage of a bunch of little 
>>programs
>> > on the device, as you don't have to waste sectors so badly.  For bigger
>> > programs though, like eBooks (With external storage, you could put them 
>>on
>> > an 83!) or big RPGs (Narkeman, etc.), the driver takes up[ precious
>> > space.  Perhaps a two-mode controller on the storage device, so that it
>> > can communicate in the high-speed, verbose mode of the driver or the 
>>basic
>>TI
>> > calc-to-calc protocol. If the special protocol were made close enought 
>>to
>> > the TI protocol, then the TI one could be made a subset of the special
>> > protocol.  Having the driver is mainly helpful with a bunch of little
>> > stuff anyway, as that when you want to see a listing of program names 
>>and
>>stuff.
>> >
>>
>>As far as I understand, getting variables to the external storage is not 
>>the
>>problem, getting them back to the calc is, right? How about a (small) 
>>driver
>>that manually sends a command to the storage? The storage could then use
>>the silent link protocol (tell the calc it's the graphlink) to place
>>programs on
>>the calc. This way, TI-OS would do most of the work, leaving extra ram for
>>the user.
>
>Using the Link menu puts all the work on TIOS.  If you do the memory 
>management on the device right, you also don't suffer the large sector 
>issues with the PSX memory card solution.  Selecting the program to return 
>on the device just needs a button to cycle through all of the sectors (this 
>brings back large sector issues) or a display that allows a browsing of the 
>tree.  The driver allows you to browse the stuff on the calc, so the device 
>is simpler.  My thought is thus:
>
>Have the device send a small program to the calc that then pulls a bigger 
>program from the device into non-program memory (like a SafeRam or 
>something) and runsit there, so that memory is preserved.  This program 
>would handle the browsing tasks all outside the memory that stuff gets 
>transfered into, so the client takes up effectively no space (the small 
>loader would delete itself after running the browser)


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail




Follow-Ups: