Allocating virtual ram either from SD card or otherwise..
A replacement set of routines that when used store the data else where (with an internet shield for example and the cloud or with an SD breakout)
Literally writing out your memory elsewhere and retrieving it ... allowing an Arduino to do some interesting things? (or am i barking up the wrong tree) ?
Allocating virtual ram either from SD card or otherwise.
Tell me about your page-fault mechanism.
Not even in the right forest, far less barking up the wrong tree.
AWOL:
Allocating virtual ram either from SD card or otherwise.
Tell me about your page-fault mechanism.
Not even in the right forest, far less barking up the wrong tree.
I never claimed it to be easy.... in theory could it be done?
(I'd store huge amounts of arrays into memory virtually, might be slow but it could also be useful)
I never claimed it to be easy.... in theory could it be done?
Without an MMU?
It depends what you mean by virtual memory.
Some kind of simple overlay mechanism, yes, probably.
Proper VM with less than a normal page-worth or at most two pages-worth of RAM to act as both RAM and page table storage?
No.
I once worked on a 6809 (8 bit data width, 16 bit address bus, so 64kbyte address space) system that had an external MMU built mostly of PALs, and had a banked architecture with up to 1Mbyte of RAM, but there, of course, we had full access to the address bus, without having to drill a package and probe the die.
(Edit: The memory pages controlled by the MMU contained only interpreted code, not native 6809, and we had to be careful how it was accessed so, for instance, every fetch from paged RAM had to be followed by a NOP, to ensure "page fault" interrupts had time to be seen by the processor before the next byte was fetched)
Without a page-fault mechanism in hardware it wouldn't be virtual memory. Closest you would get is the old idea of "overlays" but that was with the Von Neumann architecture.
Since overlays won't fly all you can really do is use the SD card as an auxiliary storage for data, which you can already do.
For example, you could use a disk file (read only) to access large amounts of data (eg. game data like rooms descriptions for an adventure game).
Or, you could even save data out, and read it back. But with only 2 kB of RAM on a Uno, and probably needing 512 byte disk sectors, the usefulness would be limited.
If you are desperate you could add on an SPI/I2C RAM chip. And the Mega lets you attach more memory.
Remember, things like the Fat library take quite a bit of program memory (and RAM for their buffers). So you are expending quite a bit of valuable resource for quite possibly limited gain.
There's a project somewhere that boots Linux on an AVR, using the AVR to emulate an ARM processor, with, IIRC, an SD card as "RAM".
It takes something like two hours just to get to the boot prompt.
To paraphrase Samuel Johnson, "Sir, booting Linux on an AVR is like a dog walking on his hind legs. It is not done well; but you are surprised to find it done at all."
Well you could use overlay programming (Google) but you'll need to rewrite GCC.
It takes something like two hours just to get to the boot prompt.
Mark
You can store as much array-data as you want, just write a C++ class that acts like a huge array then write an operator[] than accesses an SPI RAM chip (or whatever).
Normal variables, etc.? Not going to happen.
There is an "addressmod" modifier in at least one compiler I know. You define:
addressmod(EXTERNAL_RAM, write_function, read_function, 0x00000, 0xFFFFF);
where write_function() and read_function() are the functions for accessing n-bytes in any external memory device, for example from 0x00000 to 0xFFFFF range.
And then simply:
EXTERNAL_RAM int32 my_array[20000];
EXTERNAL_RAM uint16 my_array1[5000];
Must be supported by compiler, however (IEEE Embedded C standard (ISO/IEC TR 18037), B.1.2 Application-defined multiple address space support).
PS: FYI - I did experiments in past with it. 256kB SPI FRAM connected to a dspic33 mcu. Random read/write to a 32bit variable ~7usecs, with larger block access ~1usecs.. It will be more with arduino however. You may use a parallel sram, it might be faster then (bitbanging the data and addresses).
These ideas of yours... Well, you can't say the bloke doesn't think outside the box. 
There's a project somewhere that boots Linux on an AVR, using the AVR to emulate an ARM processor, with, IIRC, an SD card as "RAM".
It takes something like two hours just to get to the boot prompt.
http://dangerousprototypes.com/2012/03/29/running-linux-on-a-8bit-avr/
Literally writing out your memory elsewhere and retrieving it ... allowing an Arduino to do some interesting things? (or am i barking up the wrong tree) ?
Hark, who let the dogs out?
Seriously, the Linux example shows that one can do some pretty strange things if one wants to... I would personally never say it cannot be done, but I can say that it should not be done.
"There is nothing you cannot do with computers if you have enough time and enough money."
Ray