This looks like a very typical parallel display interface. I'm afraid it's completely impossible to drive with an Arduino alone.

You need to supply a continuous dot-clock (CL2) with a minimum of a 15ns period (66Mhz). You also need to a supply timing pulses for the vertical and horizontal blanking areas (CL1). At each tick of the 66Mhz dot clock when it's not in either the vertical or horizontal blanking areas (a.k.a porches) you need to provide a complete pixel on the data lines. You cannot pause or stop the dot-clock. The display has no "memory". You must supply data at every clock tick. In short, you need a frame buffer and a fast processor, preferably with DMA and some fast timers.

"Scrolling" is implemented in these types of TFTs by changing where in the internal GRAM line zero is sourced from so what you actually get is a wrapped display that can be made to appear to be scrolling by clearing the wrapped scan line(s) in software. In portrait mode they'll only "scroll" vertically and in landscape only horizontally.

You can see the effect in this video I took of my own graphics driver driving a Nokia 6300 QVGA TFT showing a demo of a terminal-style program. It scrolls when the output hits the bottom of the display.

Almost certainly a dry/cracked joint. Apply flux around all the pads and touch up each one carefully with a fine tip soldering iron. Usually only about 1 second of contact per pad is enough to reflow the solder and cure your bad joint. I do this working under an illuminated binocular microscope that makes spotting and correcting bad joints very easy.

If you mean to do .c file from that image I already tried to do that

I can just about imagine doing JPEG decoding on a Mega, for a very restricted set of JPEG files.
It would be exceedingly slow, and an exercise in advanced hair-loss.

It may be possible to do some other form of compression on the image, but it really depends on the image content.

If you've already got an SD card, store the image in a file as a BMP.

It's possible on the Mega for almost all JPEGs (only progressive jpegs are not supported), costs only 2.5Kb of SRAM while decoding and it's surprisingly fast. See my demo video at the bottom of this article. It won't work on the standard (2Kb SRAM) arduino - the huffman tables are just too large.

Will the final executable contain only one instance of the MPLArrary<int, 10> code, or will there be code duplication ?

There will only ever be one instance of the executable code if that's what you mean. Each compilation unit gets its own copy of the template methods in the object code but they are marked with the .weak attribute which causes the linker to discard duplicates.

Good suggestions guys, thank you very much.

What are the current requirements on the 1.8V supply?

The maximum current requirement on the 1.8V supply is 82mA.

I've got a device that has 3.3V and 1.8V power inputs. I'm providing 3.3V directly and 1.8V via an LDO regulator. The device requires that there is at least a 10ms delay between the 3.3V (first) and 1.8V (second) supplies on power up.

It's tempting to do the lazy way and buy a 1.8V regulator with an EN pin and drive that from the MCU but I've got some MCP1700 devices in stock that only have Vin/Vout/GND pins and I'd like to use these.

So how would you design a (minimum) 10ms delay circuit around the MCP1700 using the smallest number of components? I was thinking an RC delay circuit to the base of a transistor. Yes?

Is there really a fumes issue specific to using leaded solder? Lead vaporises at 1750C so surely the fumes are the flux core which you'll get in both leaded and lead-free. I use a fan blowing over my workspace to dissipate fumes.

Memory fragmentation occurs when small variables are removed from the heap to be replaced by larger variables.  The space left by the small variable is too small to accept the larger variable, so the larger variable is instead placed on the top of the heap, causing the heap to grow.  This most often occurs when working with strings and you want to add something to the end of a string (concatenate) or join two strings together.
to be shunned whenever possible.

It's actually quite hard to cause significant memory fragmentation to occur in the avr-libc implementation of the heap. free() will always coalesce blocks above and below the one it's being asked to release to create one larger block in the free list so even a poor String concat implementation that used malloc()+free() instead of realloc() would generally only end up with one block in the free list due to every second free() being coalesced with the previous one and then being big enough to satisfy the next malloc().

If you understand it, use it. If you don't, don't.

Part of the problem IS with the String class itself. When you want to append one character to an existing String, the length of the new String is the length of the old String plus the length of the String to append. That amount of space is allocated, and the old String is copied there, then the String to be appended is tacked on, then the old String's space is freed.

No this is not true. String uses realloc() which, if you'd care to read the implementation in realloc.c will always attempt an in-situ block-expansion. For most cases this will result in no pointer change at all and a simple adjustment of the allocated length - usually out into free space in most use-cases on a small system like this. A block-copy is only required if the original allocation either came from the free list and that space is now exhausted or there is a new block allocated in front of the one that needs to be expanded.

It looks like the IC is available in different packages - the suffix, or part of it, indicates the different package types. If you're working with a breadboard then you need a DIP package. The other types are likely to be various surface mount packages.

This is the one you want to ask for:

http://www.hobbytronics.co.uk/74hc4050

It also says in tutorial I can hookup without the level shifter

It's talking about the backlight.

(Arduino Uno has 3 v pin so why not)

Because the Uno GPIO levels that you are going to connect to the display are at 5V.

I have tried reading various other tutorials but everyone seems to use some sort of chip.

And rightly so. There are other ways to translate levels but an IC offers guaranteed equal propagation delays for all its ports which is important when you're translating the levels of a data bus.

You really should get a level shifting IC...

The answer is, it depends...

If the register is in the 0..31 range then if you need to set/clear more than one bit at a time then it's faster to read it with "in", set/clear with an "and" / "or" then write back with an "out". That's one cycle per instruction, 3 cycles in all.

If you need to just set or clear one bit then "sbi" and "cbi" will do it in one 2-cycle instruction. Faster if you just need to do one bit.

Be sure to check out the timing notes in the Atmel datasheet, you may need to insert a 'nop' at strategic places to achieve synchronisation depending on what you're doing.