Does the address bus always reflect the value of the PC?

[Dan Moos]

I'm writing a 6502 emulator for debugging purposes.

I'm curious. Can I treat the program counter and the address bus as basically the same thing? I'm not emulating the inner workings of the cpu. I just want the emulator to to run my real world code, so although I'm sure in the span of a cycle, they aren't always the same, I don't need that level of fidelity. I'll have a function called "cycle", which will advance the PC, (and the address bus, right?), and do the proper thing with the data bus depending on the r/w line.

Am I correct that after every cycle, the PC and address bus should match?

[GARTHWILSON]

The address bus also carries the addresses of variables or other data bytes in memory, or of I/O.

[Dan Moos]

EDIT: don't listen to me, I just realized my silly mistake

[Dan Moos]

wait...it just dawned on me. I feel dumb now...

[BigDumbDinosaur]

Dan Moos wrote:

wait...it just dawned on me. I feel dumb now...

BTW, you are writing a simulator, not an emulator. 

[BigEd]

This confusion of address bus and PC is relatively common - I remember I had it, at some early stage of my 6502 interest. It's a good departure point, really, from understanding 6502 behaviour as being a sequence of instructions, to understanding it as a series of bus accesses.

Edit: best not to feed the troll. Some people - BDD in this case - just don't learn.

[Dan Moos]

Can't help myself

What would you consider the difference between an emulator and a sim BDD?

My plan is that I can run unaltered code meant for my real hardware, and have it not be any different on my software. I am not certain how deep the simulation/emulation will go. At the moment, it's pretty faithful to the real chip behavior except that I don't yet treat a cycle as a 2 phase clock. I have a function called "cycle" that takes an argument as to whether it should advance the PC and address bus or not. If I'm feeling the need, I will make it treat the HIGH and LOW portions of the clock correctly. I'm not sure I see the need though.

Its turning out to be an easier project than I thought. Variables that represent the registers, functions for the instructions, and a endless loop that just fetches and executes instructions. Interrupts will require some thought, but not too much I think.

[BigEd]

Oh no, really not wise to feed the troll, we've gone over this so many times, and it's very simple, for anyone prepared to think. Thread here, specifically for these situations. You'll notice it's a locked thread - that's because this topic is endless, and endlessly annoying, which is why it's best left alone.

[BigDumbDinosaur]

Dan Moos wrote:

What would you consider the difference between an emulator and a sim BDD?

Simulation is an illusion. Emulation is reality. A good simulation is realistic. What it isn’t is real. Emulation is real.

As a good friend who is a captain for a major airline once said, the key difference between flight training in a simulator and flight training in an emulator (a plane whose characteristics closely mimic those of the plane for which training is being received) is if you crash the simulator, you can analyze your actions that led to the crash. If you crash the emulator, others can analyze your actions that led to the crash...after your funeral.

[BigEd]

There's only one person who keeps bringing this up - I take this to mean that everyone else has concluded that everyone already understands each other's usage, and it's infinitely more interesting and fruitful to discuss the thing that's being discussed rather than the terminology, even if we do each have our own preferences.

[JimBoyd]

And you would be wrong. I agree with BDD, I'm just not as vocal about it.
I am well aware that I can NOT do the same things with VICE ( a Commodore 64 simulator) that I could with a real Commodore 64.

[Dan Moos]

You were right Ed....

[BigDumbDinosaur]

JimBoyd wrote:

I am well aware that I can NOT do the same things with VICE ( a Commodore 64 simulator) that I could with a real Commodore 64.

Yep!  VICE lacks the hardware attributes of the C-64.  By definition, that makes VICE a simulation, not an emulation.

BTW, the C-128 can be thought of as a C-64 emulator when running in C-64 mode.  The C-128 is in many ways a different piece of hardware than the C-64, which means when it is running as a C-64 it is emulating the latter (an emulation that is not quite exact, but extremely close).

That said, I will not cause Ed any further distress by pointing out the clear difference between emulation (hardware behaving like other hardware) and simulation (software appearing to behave like hardware).  I wouldn’t want him to experience cardiac distress brought on by being exposed to facts. 

[BigEd]

Thanks BDD, if you can stop this tit-for-tat, everyone will be happier.

[Proxy]

BigDumbDinosaur wrote:

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.