It was answered above, but I can see why it may be difficult for someone who's coming into this brand new. Hopefully I can improve the primer after I understand better what your thinking is.

The reset vector and reset routine always have to be in place before the computer is released from reset to begin executing instructions. No exceptions! For this reason, these are normally in ROM, not RAM. The computer can't write to its own ROM. A ROM-programming device puts the information in the ROM before the computer is powered up the first time. Your 6502 program cannot change the reset vector. In the case of a simulator, the simulator must put the reset vector in before it starts the simulation. Your program can't do anything without the reset vector being already in place, because without it, the processor will immediately be off on the wrong address. What it tries to execute as instructions could be uninitialized ROM bytes which read out as $FF, or I/O registers, or uninitialized RAM which will just have trash, or data tables which won't make any sense as instructions. The result is that the computer is crashed immediately after coming out of reset.

When I said the code was incomplete if it does not set up the reset vector, I meant the source code, not the code that goes into the target computer's memory.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The processor is built so that when it is powered up it picks up whatever 16-bit value is stored at $FFFC/D and loads that value into the program counter. That value is thus treated as the address to start executing program instructions at.

If you think about this for a moment it should become clear that both the value stored at $FFFC/D and the program it points to both have to somehow be loaded into memory before the processor (real/simulated/emulated/whatever) is powered up. As has been mentioned, many real systems do this by having at least one ROM installed that contains both the reset vector and the program it points to. For example, a C64 contains an 8K ROM in the address range $E000-$FFFF that does this.

In a system with only RAM, whatever initializes the system as a whole has to load a binary image into that RAM before starting the processor itself. Probably not too great a difficulty for an emulated system, maybe a bit more of a trick for a real one. As an aside, if the system really has only RAM then it's not a problem to change the reset vector under program control so that future resets could theoretically behave differently (if one has a need for that sort of thing).

Two suggestions have been made for formatting a program to load into RAM before starting the processor. One is a raw binary image covering the range $4000-$FFFF. This can work but probably contains a lot of unused space (but who cares these days?). The other is an Intel HEX image the affects only the specific addresses that are actually used.

Which one to use - or some other altogether - depends firstly on what the loader (the part of the emulated system that initializes the contents of RAM before starting the processor) can handle. If it can only handle one format, your decision is made for you. Otherwise you get to decide what you're most comfortable with.

Just to be contrary...

On my simulator, I don't implement these vectors, I simply type in my starting address and hit GO.

Also, you can have a computer with nothing but RAM and a hardware only front panel. Then you could address the memory directly to store instructions and data. But then you would basically place the the starting address in the vector location ($FFFC/D in this case), and reset the processor for it to go its merry way. The vector need not necessarily be proper RAM per se either, they could be some kind of set of logic registers.

Obviously this isn't done today, but was done in the past.

Yes, the confusion here comes from a simulator being too helpful and obscuring the situation that we have in a real physical 6502 system.
There are three things which each obeys their own rules:
- the assembler which makes binary data
- the loader which places binary data in memory and optionally jumps to some start address
- the processor which resets via the reset vector

(The loader could be a ROM programmer)

Cheers
Ed

Yes, Dr Jefyll and I were just discussing privately how this could be made more clear to newcomers. When I'm the newcomer in different areas, I wish the people writing the explanations could look over my shoulder and see where my thinking goes, which is obviously not what they expected. Often I come to a major halt because of one tiny thing that they're assuming I know but I don't, and they don't provide that info anywhere.


Since there are so many newcomers who want to write a simulator, it might not be a bad idea to have perhaps a sticky topic telling of the countless ones that are already available. I agree however that a simulator is not really very productive in learning the processor anyway. In fact, I'm kind of glad I was forced to start without even the benefit of an assembler. We started in class in 1982 on AIM-65's which had a rudimentary assembler onboard, but we were to assemble by hand and punch in our resulting machine code in hex. (Fortunately our programs were only long enough to show that we understood a concept, so the manual process was not very time-consuming.) I think it gave me a better understanding of the low-level stuff than I would have gotten if I were handed all the tools right up front. Even on the many products I've developed for market, I have not been using a simulator at all.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm not completely in agreement - I think the more accessible a simulator is, the more chance someone will have a go at assembly language programming. easy6502 does a good job of embedding the simulator in a series of tutorials. It would, however, be good to add an appendix explaining how a real system boots and loads code.

I also think that writing a simulator is usually a case of scratching an itch: it doesn't necessarily mean the author wants it to become the best and only one. It's still a good service to let people know about the ones which already exist. Note that very many 6502 fans are primarily fans of games - they want a system or a simulator with appropriate I/O devices for that. The catalogue found on this site at http://6502.org/tools/emu/ is specifically aimed at CPUs not at systems.

Of course, I do agree that adding and improving the explanations in your tutorial guide will be a help!

Cheers
Ed

I definitely wrote mine to scratch an itch. I wanted to do "something" with a small computer, and I wasn't sure what it was (did I want to build one, use one, etc.).

I played around with some things, like a Z80 simulator that gave me a CP/M prompt. At which point I went "whee -- now what".

That told me I needed something lower level, and I also knew that hardware wasn't quite my game.

So, I wrote my simulator, and in the process found I "needed" to write an assembler as well. I wrote them for fun, for my own amusement and enlightenment. I had never wrote either before, so I just made it up as I went.

A pre-existing one wouldn't have really let me do what I wanted to do, and there didn't seem to be many for the Mac anyway, or really in Java.

It's a crude and simple simulator, it doesn't try to do anything in any particular realistic way. It's more a 6502 interpreter than a hardware simulator. But it serves my purposes. The better simulators are more discrete and signal aware than a gross interpreter like I have. They don't have to be at the level of Visual 6502, but they're kind of in a middle area.

And the combination of writing the simulator along with standing up the FIG-Forth on top of it taught me a lot.

I still need to add macros to my assembler (which will be a rather dramatic rewrite I think), and perhaps add 65c02 instructions to both the assembler and cpu. Then add interrupt handling, which I don't do now.

Someday I might post it to the world. It currently makes some crass assumptions on it's runtime environment.