by pointing out the clear difference between emulation (hardware behaving like other hardware) and simulation (software appearing to behave like hardware).
i know i shouldn't poke the bear but...
i don't know where you got those defintions from, but i can bet that they're pretty old... nowadays the commonly accepted (except by you it seems) defintion is
"the ability of a computer program in an electronic device to emulate (or imitate) another program or device." with "hardware emulation" specifically refering to hardware (like an ASIC or FPGA) emulating hardware. like the MiSTer FPGA (which even refers to itself as a "hardware emulator", aligning with the defintion from wikipedia)
how deep the software/hardware immediates the inner workings is up to the creator.
for example Mesen is a popular NES Emulator that is so accurate that's pretty much indistinguishable from a real NES.
meanwhile Project64, a Nintendo 64 Emulator, still has issues with some games as it doesn't really emulate the N64's graphics processor and does a lot of high level emulation instead (converting N64 to OpenGL/Vulkan calls and such), but it's still considered an emulator, just not as accurate.
but honestly i couldn't find much for "simulation" in computing, most definitions i found are very overarching and define it as a piece of software immitating any real world mechanics like, weather, physics, chemistry, biology, technology, etc.
that's all i'm hopefully gonna say to that because i don't want to derail the thread more or fuel BDD's inner troll.
.
anyways, how exactly do you plan to structure your emulator anyways? there's are loads of ways to make the CPU run with different "levels of accuracy", which in turn changes the way you interface with the rest of the system. (like Memory and IO)
for example if you go all the way down to emulating all internal registers and logic, then you likely need extra variables that reflect the state of the address and data bus on the current cycle. in which case you would need to look at and learn the deep inner workings of the 6502 to get it all correct.
or you could do it like i would and not bother with perfect cycle replicating emulation and just have each instruction do all it's work at once and afterwards count how many cycles it would've taken.
my own 65C02 emulator written in C just uses a giant switch case statement that uses the opcode as input value, after that it uses the opcode as an index into 2 arrays, one contains the size of each instruction in bytes (which is then added to the PC), and the other all the cycle times for each instruction, and returns that (+1 for crossed pages) from the function. it's pretty crude but accurate enough for testing software, allows for instruction level break points, and runs decently fast.
i would also recommend to have seperate functions for setting and clearing flags as it's a lot easier to work with and helps with readability compared to directly fiddling with the status register bits inline.
also on another note, to control the speed of the CPU you could try the following:
have a main loop, and a sub loop within it.
the main loop starts a real-world timer, and then starts the sub loop, which in turns begins executing instructions (ideally you have a function that executes exactly 1 instruction), accumulating the cycles for each executed instruction in some variable.
once the variable is equal to or greater than some defined "clock speed" the sub loop exits and now the main loop looks at how much time all that took, and waits until (1 second - the recorded time) passed to then do another iteration. so that every iteration (including the sub loop) takes exactly 1 second.
this means (on average) the emulator will run a specified amount of cycles per second, which is then whatever speed you want the CPU to run at.
hope this was somewhat helpful, and i'd be interesting to hear how exactly you want to implement the CPU.
