not quite.

a bootloader (in similest terms) is a piece of software that runs first before any OS starts. An example is LILO for Linux.

Andy, do you mean "the computer" instead of "Bootloader"?

see: http://en.wikipedia.org/wiki/Booting



Remeber that x means external. so xdata = external data.
If you want to dig deeper, you might want to use a program called asem-51 (found at http://plit.de/asem-51/). It is an 8051 assembler.

Make an assembly script file, and use the MOVX instruction to access your expanded ram.

You also might want to look at the SBC (single-board computer) found here, and at PJRC's web site (I think pjrc.com). The 8051 chip has a multiplexed address and data line. a latch is used to separate the lines so that we can get 8 data lines and 16 address lines. The address lines are very important because they can indicate which addresses are valid for MOVX.

For example, if you had an 8-byte ram chip, you will have 8 data lines, and 3 address lines. Why 3 address lines? because 2 ^ 3 = 8. If you hooked up the address lines to A0, A1, and A2 (coming from the external latch connected to the 8051), then issuing MOVX to addresses ending in any of these binary values: 000,001,010,011,100,101,110,111 will be valid and will modify your memory.
This means that address #8 and address #0 will point to the exact same memory location. why? because the the first 3 bits are only used, and the 4th bit is undefined. Given the fact that the #8 is 1000 binary, we drop everything past the 3rd bit, and we get 000 binary which is one of the values I mentioned above.

So your best bet is to fill up the addresses in order so you don't have to use complicated math. If you are using 32K (Kilobytes) of ram, your best bet is to connect A0 to A14 to the RAM and leave A15 floating for now. that way, any addresses between 0 and 32K will be unique. If you stayed with this suggestion, then you will notice that 32K - 64K mirrors 0 to 32K of ram. In other words, byte 0 is byte 32K.

Arranging your hardware is very important, because your software will work with your hardware.


Think about your variables.

If you are using strings, memory will be used very quickly.
If you need to define alot of values, use bits.
There are 8 bits in a byte. So if you had many binary states (I like to call them flags) to compare, definitely use bits.

You might have to add extra code to compare bits, but memory wise, it is well worth it.

If that doesn't work, you could try to compress your variables.
By that, I mean make a smaller representation of a large value.

For example, if you declared a string in a slot of memory, and your sting was equal to lets say:

AAAABBBBCCCCDDDDEEEEFFFF

you will be using 24 bytes of memory.

The easiest way to compress it, but not the absolute best is to make the output like this:

4A4B4C4D4E4F

All I did there was count each letter, and prefix it with the number of that letter.

That takes 12 bytes of memory, a nice reduction.

But if you really got desperate, and conditions permit, you could increase the math.

What if we were to convert the values.

Let's define the maximum number of repeated characters we will allow. Let's say 8.

this means that our value must be <= 1000 binary.

So we can write:

4A4B4C4D4E4F

as (in bits):

0100 01000001 0100 01000010 0100 01000011 0100 01000100
0100 01000101 0100 01000110

Adding all this up, we get a total of 72 bits, which equals to 9 bytes. We saved 3 bytes!

I can't go on forever, but you now get the idea that good compression and good logic can make 32KB of memory an extremely large amount of space to play with.