This might be a stupid question.I'm new so please answer in simple terms 
.So I am making an arduino retro computer.It has its own OS.The OS is stored on the atmega328 chip.The external flash memory is a micro sd card.I am using this sd card reader: http://www.adafruit.com/products/254.My question is,can I load a program onto the arduino through an sd card.I don't mean re-flashing or uploading a new sketch.I mean opening an application(ex.a game,a text file,etc.)inside the OS without re-flashing the chip.Please tell me if my problem doesn't make sense.I know its a bit complicated.In simpler terms,can I open and run a file or folder from the sd card with the arduino without re-flashing the chip?example:suppose I want to run tetris on the retro computer.The tetris code is stored on the sd card.How can I open and run the tetris file from the sd card,without restarting or re-flashing the arduino.
The Arduino architecture does not permit user code to run from SRAM, so loading native code from SD is not possible; but you can run an intrepreter such as Bitlash.
Bitlash Home Page
Ray
I don't really understand sorry i'm kinda new.So I can't run code from the sd card without reflashing?
zack1544:
This guy did:https://www.youtube.com/watch?v=kh0PRjo7s8g
He must have written his own bootloader code.
...R
He said something about flashing the loader program into the memory.I'll check the gamebuino site for more details.
ya you are right.He made a bootloader.Can I use the his bootloader it in the retro computer?or is it only compatible with the gamebuino?He has the bootloader download on his site.How do i burn the new bootloader onto the atmega chip?
thanks for responding
zack1544:
Can I use the his bootloader it in the retro computer?or is it only compatible with the gamebuino?He has the bootloader download on his site.
I don't know anything about the gamebuino so I can't answer your question.
...R
ya you are right.He made a bootloader.
Hopefully he posted the necessary instructions for flashing (and fuse settings) along with the boot loader code. The Gamebuino is not a system that I am familiar with... If they have their own forum, maybe someone there can assist.
Ray
zack1544:
ya you are right.He made a bootloader.Can I use the his bootloader it in the retro computer?or is it only compatible with the gamebuino?He has the bootloader download on his site.How do i burn the new bootloader onto the atmega chip?
Think of it this way:
Your OS is in the flash on the 328, ok? So then you have something in/on this OS that can take a hex file off the SD card and flash it, just like a bootloader does (let's assume this would work) - so now you've flashed it on - and your OS is where...?
Gone. The flash was overwritten by the other program.
Now - this might not be so bad - if the other program also has a way to flash the OS (or another program) back when it was done.
But first some basics: The bootloader is a special program for the ATMega328. When the 328 boots, it starts executing at address 0 in the flash RAM (IIRC). At that address is located the beginning of the bootloader. The memory of the ATMega328 is broken up into 512 byte chunks; for the bootloader, it occupies one of these chunks (earlier bootloaders occupied 4 chunks - or 2K) - in fact, 512 bytes is the smallest chunk a program can occupy - so even if you wrote a smaller program that compiled to say, 280 bytes, it will still take up one of those 512 byte chunks.
Anyhow, the bootloader occupies that first chunk, and is executed immediately on startup. There are these "switches" (called "fuses") which can be changed via an ICSP programmer (which is how the bootloader is put on the 328) to protect any particular chunks from being overwritten (marked "read only"). The chunk the bootloader is on is marked in such a manner.
So - the bootloader runs, waits for serial input (for a few seconds) - if if none occurs (ie - and upload of hex code to be flashed) - it jumps to byte 512 (start of second chunk, where the hex binary start of a loaded sketch is stored), and begins execution of the sketch (at the binary level, a sketch can jump from chunk to chunk across the boundries; I don't recall if this is an automatic thing, or something that has to be done in code, like you had to do in DOS to cross the 64K segment boundry).
If it sees a serial upload, it takes those bytes, and begins stuffing them into bytes 512-32767 (or however many bytes are needed), then when done, starts execution at byte 512. At no point does the bootloader write (nor can it) to bytes 0-511, where the bootloader lives - because to do so would kill the bootloader (and likely cause problems).
So - here's what you could do (and you'll need a much better understanding of the ATMega328 - in fact, my understanding above is likely causing many people to cringe - I am sure I have more than one thing wrong, but I think the gist is there):
- First off, in the 32K of ram, there are 64 of these 512 byte chunks - so write your "operating system" to fit in only a few of them (say 2-4K, or 4-8 chunks - or maybe more).
- When they are written, protect them from being overwritten. The others can still be written to.
- As part of the OS, it needs a way to write to the other chunks (code from one of the bootloader examples would work). It also needs a way to read the hex from the SD card.
- When the ATMega is started, it runs the OS. At some point, someone signals the OS to load a program from the SD card.
- The OS reads the hex code stored on the card, gets its size, and if it will fit into the remaining space - if not, display an error.
- Otherwise, write the code from the hex file to the remaining chunks. When done, start execution at the beginning (just like the bootloader code does).
- Then - in the programs - you need to make sure it has a way to exit, and when it does, it should start running the code for the OS (at address 0) again. There may be a way to trigger a reset of the ATMega programmatically - if so, that would be the best way to "start the OS" over again.
That's how I'd approach things, anyhow. That is, if I insisted on staying with a compiled system. Suffice it to say, you would need to really dig into the weeds for this system; likely you will need to write (and understand) more than a little bit of ATMega328 assembler code in order to make this work best. Not everything has to be done in assembler; bootloaders consist of intermingled C/C++ and inline assembler directives - so your OS can be designed in a similar manner.
The other option, as noted by others (ie - bitlash, etc), is to create an OS that can "execute" custom interpreted "intermediate" code - this code could be stored as a text file or such on the SD card, read off, and executed by the OS code. The tradeoff is while this is simpler (arguably) to implement than the above, it will suffer from speed of execution (it won't be anywhere near as fast as "native" code) - but you can store many more "programs" on the SD card, and in theory, the programs could be fairly long (if stream processed by the interpreter - not loaded all at once into RAM and executed).
Also - regarding the Gamebuino - likely it has a bootloader that is only 512 bytes or 1K or so long, and it looks on the SD card for a hex file (instead of waiting for serial input) - if it finds one, it flashes the hex to the Arduino as normal, and executes it. To load another game, you put in a different card with a new hex file, then re-boot and it reloads the new game. Nothing special - just a different source for the hex file as compared to the standard bootloader. That isn't to say that such code couldn't be used as a base for your own "OS" riff.