> This sounds more like the overlays that some old DOS programs used
> rather than a DLL.  This would be feasible for very rarely used
> functions, but flash memory wear and erase/programming times may well be
> a problem for anything else.
>
> You would probably have to allocate a block of RAM that would be used
> only by the paged code and you would have to handle any initialisation
> of this memory yourself.
>
> Regards
>
> Mike


MANY years ago, I used banked RAM on an MC6802 project. We licensed
Microsoft 6800 Basic for the product. With a 64kB memory map and memory
mapped I/O, we ran out of space in larger systems. The system had the
EPROM firmware at the top of the memory map and RAM at the bottom
(starting at address 0). I/O was between the two. Several banks of RAM
could be switched in starting at address 8192 (decimal). Below that, the
RAM was common to all banks.

Here's a little bit from the manual:

LOAD EEPROM B,A Loads a program from non-volatile memory (EEPROM or
battery backed RAM) at bank B, address A. This may be used for
non-volatile storage of LOAD EEPROM 2,8192 programs in systems with
multi-bank RAM. Note that addresses 0 thougn 8191 are in common to all
banks. Therefore, address 8192 of bank 2 is suggested for non-volatile
storage.

On the LOAD command in general, I wrote:

If LOAD is used within a running program, the
running program is deleted, the new program is
loaded and run. This allows for simple chaining
of programs. If the comma and drive number is
deleted, drive 8 is assumed. Note that LOAD does
not delete variables. If variable deletion is
required, the LOAD should be preceeded by a
CLEAR. Since a LOAD does not delete variables,
simple program chaining can be accomplished. For
example, a run-time program may be broken down
into an initialization program that initializes
all variables and an operating program that
actually does the work. When initializing string
variables, however, they need to be copied into
=93string space=94. This can be accomplished by
concatenating each string with a null string as
it is defined. ie: READ LB$(N):
LB$( N)=3DLB$( N)t=94=93. Without this copying, H&F
Basic sets up a pointer into the program to
reference a string literal, saving RAM. Once a
different program is loaded, these pointers would
be invalid. Forcing the copying of strings into
string space in the initialization program allows
these strings to be referenced properly in the
operating program. Utilizing an initialization
program and a run-time program allows the DRC to
perform more complex tasks. In addition, seldom
accessed menu items in the operating program
could load the code for the task from disk or
non-volatile RAM, again saving RAM space.

This manual
(http://louise.hallikainen.org/BroadcastHistory/uploads/HfDrc190.pdf) was
last updated in 1989. I probably started the project around 1985...


-- =

FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist