Re: [cc65] C128 Bank Switching and cc65

Okay, this is just a random thought, but could you create a piece  
table in code, which tracks each listing added to the list, and the  
changes to the list as the user traverses it and changes are made,  
and then links to a cache area of memory where you keep a handful of  
filenames in a linked list. So you've got a chunk of your list as a  
cache, just enough to display the current screen, and the rest of the  
listing is in a file on disk, which is where your piece table points to.

Sorry, I'm doing a horrible job explaining this.

Okay, it's like a text editor using a piece table. There a table of  
value for chucks of text. When you open a file with text, the piece  
table has an entry, start of file to end of file. Then, when the user  
types an extra line of text, the actual text typed in gets written to  
a file, a cache file if you will. An entry is added to the piece  
table contain the start and stop points to the text that was written  
to the cache file. Thereafter, every change, or delete, or insertion,  
is made up of changes to a piece table, which holds the start and  
stop points for blocks of text in the original file and the file that  
contains blocks of text the user has typed during their session. The  
screen display only has to load and render the currently viewed  
section of the document. The document itself is unlimited in file  
size, but you only need enough actual system memory for the piece  
table. ALL the text is stored in 2 files. As the user types, the  
second file gets bigger and bigger. When the user saves the file, the  
piece table is used to assemble a new third file which then  
overwrites the original file.

So, you could treat your direction listing in the same way. Write out  
a text file of all the filenames in a directory. Then use your piece  
table to record the order of the files. When a new file is saved, you  
add the new file's filename text to your temp file. Your piece table  
gets an entry for the new file, so your directory generator function  
knows about it (and the piece table could track the date or other  
order data). When you delete a file, you don't re-write the output  
filename file, you just add an entry in your piece table to NOT  
display this file as it doesn't exist anymore.

So, the on memory you need, is the piece table, and perhaps a cache  
of it, or instead a screen buffer. Then, as the user scrolls through  
the very long list, you use the piece table to determine what  
filenames' text you need to load into the display. In theory, and  
unless my nighttime vitamins was made my brain and writing all wonky,  
I think this should support an unlimited number of filenames, without  
ever using more than either a screenbuffer worth of memory, or a  
cache file that contains a block of filenames kind of around where  
the user is looking, so that scrolling up and down over the same 2  
areas back and forth doesn't hit the disk over and over again.

Here's a great walk through of someone making their own text editor  
using piece tables
http://www.catch22.net/book/export/html/14

I have designed my own text editor using piece tables for the  
Commodore PET, but I haven't started writing it yet. I worked out on  
paper all the modules and buffers and everything, I just need to do  
it. :)  Maybe when I'm not busy with PetSynth synths and FlytrapGear  
guitar pedal circuits, haha !

Sorry so long! I hope I didn't ramble too much!
-Chiron


On 4-May-10, at 8:30 PM, Payton Byrd wrote:

OK, I'm at the point where the 128 version of my program is simply  
running out of RAM and is incapable of storing large directories any  
longer.  The executable code is around 17.3K and I don't know how to  
tell the running size, but I can tell you that another 2000 bytes are  
consumed by the VIC screen buffers.  I'm looking for suggestions on  
how to free up some RAM or how to use banking intelligently with cc65.

I see from the C128 PRG that it's possible to setup 16K of RAM that  
is "shared" between both 64K banks of RAM; in other words a write to  
the "shared" memory results in the same data being available when  
using either bank 0 or bank 1 of RAM within the "shared" memory  
areas.  I'm wondering if the linker can be configured to write  
specific segments of C code into the shared memory which would allow  
me to  have two 48K blocks to work with for data instead of a single  
48K block (which has to include VIC, IO blocks and the kernel).

Another question I have is whether or not the default C128 memory  
setup used by ld65 disables the BASIC ROM and frees that memory up  
for RAM.  the BASIC ROM for the 128 is HUGE compared to the 64 and I  
don't need it!  Likewise, does the default C64 memory setup used by  
ld65 disable the BASIC ROM?

Finally, and this has nothing to do with banking, is it possible to  
have a specific array be allocated to a specific memory location?  I  
would like to be able to memcopy the VIC's screen from one page in  
the 16K allocated to the VIC to another page in the 16K allocated to  
the VIC.  This would free up 1000 bytes of main memory for me.  If I  
could also do this with the color map then that would free up another  
1000 bytes of main memory for me.

Thanks again to everyone for the their help the last couple of  
weeks.  This project would not be anywhere near the state it's in  
without your help.
-- 
Payton Byrd
<http://www.paytonbyrd.com>
<http://it.toolbox.com/blogs/paytonbyrd>


----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.