II thought it was pin 5, not pin 1, so your example wouldn't make sense no matter what.
Well, is reset configured as reset or I/O? Quick tests would be:
If you have a volt meter/DMM: Upload a sketch that simply does pinMode(pin,OUTPUT), digitalWrite(pin,LOW); in setup (replace pin with the number of the reset pin). and nothing else. Measure the voltage between that pin and ground. If it's 0, then the pin is configured as GPIO, because you were able to write it low. If it's ~Vcc, then it's reset, because your GPIO commands didn't work and it always has the internal pullup enabled when it is configured as reset.
if you don't have a DMM, just upload blink so you have a blinking LED and then connect ground to P5/reset. If the LED stops blinking (the led that was blinking will stop and turn off) then reset is configured as reset, if it keeps bnlinking, than reset is an I/O pin.
If the pin is configured as reset, you do not have to write any code. As long as reset is held low, the chip will be in reset state, all pins will be set input and it won't do anything until reset is released. As soon as it is released, the sketch will begin executing.
If reset is configured as an I/O pin? What you posted will ALMOST work if the intent is for it to not run the code and never run it if the button was pressed at startup, regardless of the present state of the button, until you power cycle or otherwise trigger a reset (but I don't see how else you could without resetpin and your code in an infinite loop).
As written though, you're relying on digitalRead being slow enough that the weak pullup will have had time to pull the pin up by the time it actually looks at the pin. That's not a safe assumption, as that s a very weak pullup if it's the reset pin, and ATTinyCore's digitalRead is faster (and uses less flash!) than t does on most parts, so it's only a few clock cycles, and you lose 2 to the digital input buffer's synchronizer. A simple delayMicroseconds(1) after the pinMode in your code will harden it against that sort of problem (or #include <util/delay.h> at top and then _delay_us(1) - if short on flash; that s a better implementation of microsecond delay, but only if the argument is known at compile time - otherwise _delay_us() doesn't work; 2.0.0 of ATTinyCore will automatically use _delay_us() for compile-time-known delays.
void Setup(){
pinMode(1, INPUT_PULLUP); // CHECK THE PIN NUMBERS!!!
delayMicroseconds(1);
if (digitalRead(1) == LOW){
while(1);
}}
If you instead want to delay code execution UNTIL that button is released (ie, almost emulate what the pin would do if it were a reset pin),
void Setup(){
pinMode(1, INPUT_PULLUP); // CHECK THE PIN NUMBERS!
// No need for delay - the below loop will delay for the fraction of a microsecond it takes to pull the pin up if nothing is connected.
while(digitalRead(1) == LOW);
}
