Does using ArduinoISP over write the boot loader?

I have just started playing with stand alone ATmegas and have successfully managed to upload boot loaders and sketches using an Arduino Nano as an ISP. I have noticed that the sketches on the ATmega chip start straight away. Does this mean I have over written the boot loader?

If so, does this mean I do not need to upload/use the boot loader?

MartynC:
I have just started playing with stand alone ATmegas and have successfully managed to upload boot loaders and sketches using an Arduino Nano as an ISP. I have noticed that the sketches on the ATmega chip start straight away. Does this mean I have over written the boot loader?

Yes.

MartynC:
If so, does this mean I do not need to upload/use the boot loader?

Yes.,

Many thanks

Actually, you have not necessarily overwritten the bootloader as such, but you have altered the start vector to point to your code instead of the bootloader.

There are ways of generating binaries which would not do this.

Probably the other way around. If you program using ISP, the start vector (fuse) isn't changed, but the bootloader itself is erased (ISP programming starts with a chip-erase operation, because it's the only way to erase memory.) Fortunately, the chunk of erased memory is equivalent to some useless instruction, and the code quickly wraps around to the real sketch at the beginning of memory.

Ah yes, so we get back to the trick of attaching the bootloader image to the sketch that is being uploaded and - Bob's your uncle!

The only tricky bit appears to be splicing the code images and apparently, removing an intermediate "end" record.

Paul__B:
Ah yes, so we get back to the trick of attaching the bootloader image to the sketch that is being uploaded and - Bob's your uncle!

The only tricky bit appears to be splicing the code images and apparently, removing an intermediate "end" record.

I don't see the point of doing something like that. If you are uploading via ISP why would you need to have the bootloader also included? And if you are using the bootloader why upload sketches via ISP?

Seems pretty cool to have a choice as we do, but why try and make it more complicated then it needs to be?

retrolefty:
I don't see the point of doing something like that. If you are uploading via ISP why would you need to have the bootloader also included? And if you are using the bootloader why upload sketches via ISP?

True enough for basic experimentation, but becomes relevant for flashing "raw" chips to put in new boards.

I have been playing experimenting a little more.

I have uploaded a modified Blink sketch to a ATmega328P-PU using ArduinoISP on a Nano and the below is what I get from Nick Gammon's chip detector.
This is saying a boot loader is in use but the actual boot loader is FF's so it appears the sketch is not over writing the boot loader just erasing it. The chip previously had the Duemilanove boot loader on it.

Why would it say I am still using a boot loader?
If the chip thinks I have a boot loader why does the sketch work? I would have thought a boot loader full of FF's would cause it to crash.
Or, as per Paul__B, have I altered the boot vector to point to the sketch rather than the boot loader?
Or, as per westfw, is the chip ignoring/ jumping past the FFs in the boot loader memory?

If I do not need to use a boot loader how do I reclaim the lost space? Is it a case of resetting the start vector(fuse) and is this something a novice can handle?

Are there sketches / methods that give more detailed information about the chip? (I only have Arduinos, no dedicated programmer.) For example how do I find out where the start vector is pointing to?

Atmega chip detector.
Entered programming mode OK.
Signature = 1E 95 0F 
Processor = ATmega328P
Flash memory size = 32768
LFuse = FF 
HFuse = DA 
EFuse = FD 
Lock byte = FF 
Clock calibration = 86 
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 2048 bytes starting at 7800

Bootloader:

7800: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7810: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7820: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7830: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7840: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7850: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7860: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7870: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7880: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
.
.
.
.

7FC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7FD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7FE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7FF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

MD5 sum of bootloader = E0 DE EB D3 C3 F5 60 21 2A F1 7C 68 B9 34 4B AE 

First 256 bytes of program memory:

0: 0C 94 61 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
10: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
20: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
30: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
40: 0C 94 AC 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
50: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 
60: 0C 94 7E 00 0C 94 7E 00 00 00 00 00 24 00 27 00 
70: 2A 00 00 00 00 00 25 00 28 00 2B 00 00 00 00 00 
80: 23 00 26 00 29 00 04 04 04 04 04 04 04 04 02 02 
90: 02 02 02 02 03 03 03 03 03 03 01 02 04 08 10 20 
A0: 40 80 01 02 04 08 10 20 01 02 04 08 10 20 00 00 
B0: 00 07 00 02 01 00 00 03 04 06 00 00 00 00 00 00 
C0: 00 00 11 24 1F BE CF EF D8 E0 DE BF CD BF 11 E0 
D0: A0 E0 B1 E0 E8 E5 F4 E0 02 C0 05 90 0D 92 A4 30 
E0: B1 07 D9 F7 11 E0 A4 E0 B1 E0 01 C0 1D 92 AD 30 
F0: B1 07 E1 F7 0E 94 1B 02 0C 94 2A 02 0C 94 00 00

MartynC:
I have been playing experimenting a little more.

I have uploaded a modified Blink sketch to a ATmega328P-PU using ArduinoISP on a Nano and the below is what I get from Nick Gammon's chip detector.
This is saying a boot loader is in use but the actual boot loader is FF's so it appears the sketch is not over writing the boot loader just erasing it. The chip previously had the Duemilanove boot loader on it.

Yes, chip is erased prior to uploading sketch via ISP.

Why would it say I am still using a boot loader?

Most likely just determining via the fuse bytes which say to reserve flash space for bootloader.

If the chip thinks I have a boot loader why does the sketch work? I would have thought a boot loader full of FF's would cause it to crash.

No, I think FF's are like a nop and it just wraps around to address zero where the sketch code does start.

Or, as per Paul__B, have I altered the boot vector to point to the sketch rather than the boot loader?
Or, as per westfw, is the chip ignoring/ jumping past the FFs in the boot loader memory?

If I do not need to use a boot loader how do I reclaim the lost space? Is it a case of resetting the start vector(fuse) and is this something a novice can handle?
The memory size variable in the board's entry in the board.txt file tells the compiler/IDE what the maximum memory address is.

Are there sketches / methods that give more detailed information about the chip? (I only have Arduinos, no dedicated programmer.) For example how do I find out where the start vector is pointing to?

AVR datasheet for the chip being used is the best reference for more detailed information

Atmega chip detector.

Entered programming mode OK.
Signature = 1E 95 0F
Processor = ATmega328P
Flash memory size = 32768
LFuse = FF
HFuse = DA
EFuse = FD
Lock byte = FF
Clock calibration = 86
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 2048 bytes starting at 7800

Bootloader:

7800: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7810: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7820: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7830: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7840: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7850: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7860: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7870: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7880: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
.
.
.
.

7FC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7FD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7FE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
7FF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

MD5 sum of bootloader = E0 DE EB D3 C3 F5 60 21 2A F1 7C 68 B9 34 4B AE

First 256 bytes of program memory:

0: 0C 94 61 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
10: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
20: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
30: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
40: 0C 94 AC 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
50: 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00 0C 94 7E 00
60: 0C 94 7E 00 0C 94 7E 00 00 00 00 00 24 00 27 00
70: 2A 00 00 00 00 00 25 00 28 00 2B 00 00 00 00 00
80: 23 00 26 00 29 00 04 04 04 04 04 04 04 04 02 02
90: 02 02 02 02 03 03 03 03 03 03 01 02 04 08 10 20
A0: 40 80 01 02 04 08 10 20 01 02 04 08 10 20 00 00
B0: 00 07 00 02 01 00 00 03 04 06 00 00 00 00 00 00
C0: 00 00 11 24 1F BE CF EF D8 E0 DE BF CD BF 11 E0
D0: A0 E0 B1 E0 E8 E5 F4 E0 02 C0 05 90 0D 92 A4 30
E0: B1 07 D9 F7 11 E0 A4 E0 B1 E0 01 C0 1D 92 AD 30
F0: B1 07 E1 F7 0E 94 1B 02 0C 94 2A 02 0C 94 00 00

MartynC:
If I do not need to use a boot loader how do I reclaim the lost space? Is it a case of resetting the start vector(fuse) and is this something a novice can handle?

Three is no "lost space" - you could use the bootloader space for your program and in fact if your program gets too large, using the bootloader space and programming via ISP is how you use up all the available flash.

However, unless you reset the start vector, execution will start where the bootloader is expected to be. You have the option of deliberately loading your own start-up code in the bootloader area, or resetting the start fuse. The latter is readily do-able with avrdude, though I am not familiar with the details but I am sure Nick's tutorials will guide you.

I just change the.upload maximum_size in the boards.txt file to use all memory for SPI.
For example: atmega328o.upload.maximum_size=32768