Defining the board as Uno does the trick and lets me upload the sketch.
What I don't understand is that I BURNED the SAME bootloader to both Nanos (mine and the standard). And to the standard, there was no problem and it acted "normally" where mine does not.
Glad you got it working. I'm not sure why there would be a difference if you burned the same bootloader on both boards...unless maybe the burn of the real Nano didn't work so it still has the original Duemilanove bootloader? I can tell you that I've successfully reflashed my Nano 3.0 with OptiBoot and it works fine when I upload sketches to it using "Uno" as the selected board type.
If that is true why does the core's board.txt have an entry for just some boards but not for instance the Uno board?
#nano328.build.variant=eightanaloginputs
I'm not one of the original Arduino development coders so I can't speak to why they wrote it that way.
What I can say is that all eightanaloginputs/pins_arduino.h does is include standard/pins_arduino.h but redefines NUM_ANALOG_INPUTS to be 8 instead of 6.
The only place NUM_ANALOG_INPUTS is used is in in boards.h where it sets TOTAL_ANALOG_PINS, and the only place that's used is in IS_PIN_ANALOG(), which doesn't appear to be used anywhere.
As far as I'm aware the only place where the number of analog pins would be relevant is in analogRead(), and the only thing analogRead() cares about is if you're sending it 0-7 (the analog pins by themselves) or 14-21 (the analog pins' digital pin equivalences).
In any event, this code compiles & uploads fine when the board type is set to "Uno":
void setup(void) {
Serial.begin(9600);
}
void loop(void) {
Serial.println(analogRead(7));
delay(250);
}
but of course it won't actually do anything unless you're using an ATMega328 with A6 & A7.